In the last couple of month I was writing some flows using Spring Webflow 2. I knew that I (in theory) I could test them but I never did. The overall documentation of Webflow 2 is not that great at the moment, so I hope to improve that a little bit.
Spring Webflow 2 supports only JUnit tests so far. I guess this will change at some point but until then you have to pull out that junit.jar again.
Sorry for the awkward line breaks. Spring just does love long method and class names (which is not that bad).
Your Testclass needs to extends AbstractXmlFlowExecutionTests and to implement protected FlowDefinitionResource getResource(FlowDefinitionResourceFactory resourceFactory).
public class MyWebflowTest extends AbstractXmlFlowExecutionTests
protected FlowDefinitionResource getResource(
FlowDefinitionResourceFactory resourceFactory) {
FlowDefinitionResource flowDefinitionResource =
resourceFactory.createResource("flows/administration/skinManagement.flow.xml");
return flowDefinitionResource;
}
If your flow now happen to have a parent flow you are in a bit of trouble. You just can include one flow in the FlowDefinitionResource. The parent tag in your flow points to an id of the parentflow which is usually defined in a webflow configuration file. If this parent flow again has parents as well…yes, same game again.
To get a hold of these flows you need to override getModelResources[].
@Override
protected FlowDefinitionResource[]
getModelResources(FlowDefinitionResourceFactory resourceFactory) {
FlowDefinitionResource[] flowDefinitionResources =
new FlowDefinitionResource[3];
flowDefinitionResources[0] =
resourceFactory.createResource("flows/common.flow.xml");
flowDefinitionResources[1] =
resourceFactory.createResource("flows/common-exceptionHandling.flow.xml");
flowDefinitionResources[2] =
resourceFactory.createResource("flows/common-menu.flow.xml");
return flowDefinitionResources;
}
If one of your flows is using beans you want to mock them in the test. You can do that by registering with the MockFlowBuildContext. The method configureFlowBuilderContext will be called by AbstractXmlFlowExecutionTests
@Override
protected void configureFlowBuilderContext(
MockFlowBuilderContext builderContext) {
builderContext.registerBean("validationExceptionHandler",
new ValidationExceptionHandler());
builderContext.registerBean("infastructureExceptionHandler",
new InfastructureExceptionHandler());
builderContext.registerBean("springSecurityExceptionHandler",
new SpringSecurityExceptionHandler());
}
With this setup you now can start testing the flow.
...
public void testSkinManagementView() {
MockExternalContext mockExternalContext = new MockExternalContext();
startFlow(mockExternalContext);
assertFlowExecutionActive();
assertCurrentStateEquals("showSkinManagementOverview");
}
...
I think the code is pretty self explanatory.
You have several possibilities including start and resume flow and assert certain states. You can test action methods doing something (like calling a service) and making sure the correct flow is executed.
Figuring out the initial setup with the parent flow and beans was the most time consuming task. You need to make sure that you only put flow logic in the definition of the flow since that is what webflow is for. I think with some clever usage of set and result you can make things complicated and a bit tricky.
We are using JSF, Facelets and Spring Webflow in the product I’m currently working on. What bugged me for some time already was that when we started to refactor the domain and the corresponding dto’s the GUI was a problem since the variables which get pulled out of the webflow are just string declarations. I had to go to each xhtml file and change the code to reflect the access to the new properties.
For some reason I missed a feature of IntelliJ IDEA completely.
If you are using Spring Webflow your code might look like this:
<tr:outputText value="#{flowScope.myViewBean.creditCardDto.fullName}"/>
You get no code completion nor refactoring security.
Now it is possible to make this a little bit better.
<c:set value="#{flowScope.creditCardDto}" var="creditCardDto"></c:set>
<!--@elvariable id="creditCardDto"
type="net.wehrens.accounting.CreditCardDto"-->
<tr:outputText value="#{creditCardDto.fullName}"/>
With the clever Inspection ‘Declare External Variable in Comment Annotation‘ (just press Alt+Enter on the usage of creditCardDto) IDEA creates a comment annotation which tells the IDE of what type the given variable is. Since you are using webflow, you would pull the needed variable with a c:set tag out of the flowScope (or any other scope) and then declare the variable and it’s type.
There you go.
You can now start refactoring the creditCardDto and the GUI will reflect the changes. No more manual editing.
To make sure the comments do not get rendered out to the client (and with that the class information) you can turn that off for faclets in the web.xml configuration.
<context-param>
<param-name>facelets.SKIP_COMMENTS</param-name>
<param-value>true</param-value>
</context-param>
This is not specific to JSF, facelets or anything. This works with Freemaker, JSP’s and others as well.
My life just got a whole lot better.
You use Spring in your application everywhere. You love it. Everything gets injected and is configured by Spring. Great. Why not use the same technology to wire up your tests?
The bottom line is: Starting the Spring Context all the time in your tests drags you down at the costs of development time.
Here is why:
1. Turnaround times are much faster
When you discover a bug which might have not been covered by tests yet (this happens to me all the time) you are much faster rerunning your tests without the application context. In the application I’m working on it takes about 20-25 seconds to run a test with application context, whereas a pure unit test just takes 1 second. Now imagine this: changing some code and rerunning tests like 100 times saves you a lot of time. The tests run faster, you don’t get distracted because you could do something else in those 20-25 seconds, like browsing some web pages (you want to be efficient and use the ’spare’ time to read up the newest stories on infoq.com). But then you need to switch windows, read something, switch back, wonder what you did, rethink the problem and so on. In the end it costs you much more time than it seems.
2. Enables you pratice Test Driven Development
Since you can run test faster without the Spring context, you can start doing Test Driven Development. Before any line of production code gets typed into your IDE, write the test. That the code does not compile is the first test, go fix it by writing the actual stub for the class which you want to test. Now onto the next test. It fails, you implement the feature and rerun the test. This goes on and on and on until you fully implemented the requirements. It forces you only to implements the things needed and not more.
Uncle Bob’s three rules of Test Driven Development
1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
Learn more about Test Driven Development with Uncle Bob.
Without fast unit tests you just can’t do TDD.
3. No corrupt test configuration
Depending on the setup of the project you might have an extra Spring application context configuration for tests. You have to configure and keep it up to date. Things can go wrong here and will be detected very late.
If you use the application context in tests you get the beans injected but sometimes you need to mock them, because you depend on an application server, a database or an external service which you don’t want to start up every time you run tests. You must be very careful with that. Using mocks with Spring application context can be very powerful but also very dangerous. You have to make sure that you remove the mocks after you are done with your tests (and reinject the right ones) or mark the methods which are injecting mocks with the DirtiesContext annotation so Spring can reload them. I did debug forgotten DirtiesContext annotations one too many times. The mock object lives on in your context and 282 test later an exception occurs for no reason and you start debugging at a wrong place.
You will not discover those mock problems until you run the full suite of tests. Since your tests are slow you not very likely to run all the on a regular basis to see if everything plays well together. No, you run all tests right before checkin and then start to wonder why some tests somewhere fail. Depending on the size of the changes and the project it will require some substantial amount of time to find and fix the problem.
You might say: “But I need my application context in the tests. My Service which I want to test has so many dependencies, I just can’t mock them all!”
While this happened to me as well it might turn out that this service is maybe doing too much. Split the functionality into smaller packages and test them individually (that’s the S in SOLID principles). The danger in testing a complex service with mocks only is also that you might end up mocking everything and you don’t do any real tests anymore (happened to me, I threw hours of coding away).
There is one reason to run tests with a Spring application context. It’s just not in unit tests. If you want to test the integration with external services (like databases or webservices) you need to use it of course. Just make sure you really just test the interaction between your service and the external interface and not more (but even that is debatable in some cases). That’s what I call an integration test.
Do you use Spring in your unit tests? What experiences did you make?
