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.