Java Doc for AbstractFlowExecutionTests.java in  » Workflow-Engines » spring-webflow-1.0.4 » org » springframework » webflow » test » execution » Java Source Code / Java DocumentationJava Source Code and Java Documentation

More specifically, a typical flow execution test case will test:

• That the flow execution starts as expected given a request from an external context containing potential input attributes (see the AbstractFlowExecutionTests.startFlow(MutableAttributeMap,ExternalContext) variants).
• That given the set of supported state transition criteria a state executes the appropriate transition when a matching event is signaled (with potential input request parameters, see the AbstractFlowExecutionTests.signalEvent(String,ExternalContext) variants). A test case should be coded for each logical event that can occur, where an event drives a possible path through the flow. The goal should be to exercise all possible paths of the flow. Use a test coverage tool like Clover or Emma to assist with measuring your test's effectiveness.
• That given a transition that leads to an interactive state type (a view state or an end state) that the view selection returned to the client matches what was expected and the current state of the flow matches what is expected.

A flow execution test can effectively automate and validate the orchestration required to drive an end-to-end business task that spans several steps involving the user to complete. Such tests are a good way to test your system top-down starting at the web-tier and pushing through all the way to the DB without having to deploy to a servlet or portlet container. In addition, they can be used to effectively test a flow's execution (the web layer) standalone, typically with a mock service layer. Both styles of testing are valuable and supported.
author:
   Keith Donald

Note: signaling an event will cause state transitions to occur in a chain until control is returned to the caller.

This is the most flexible of the start methods.

Note: signaling an event will cause state transitions to occur in a chain until control is returned to the caller. Control is returned once an "interactive" state type is entered: either a view state when the flow is paused or an end state when the flow terminates. Action states are executed without returning control, as their result always triggers another state transition, executed internally. Action states can also be executed in a chain like fashion (e.g. action state 1 (result), action state 2 (result), action state 3 (result), view state ).

If you wish to verify expected behavior on each state transition (and not just when the view state triggers return of control back to the client), you have a few options:

First, you may implement standalone unit tests for your org.springframework.webflow.execution.Action implementations. There you can verify that an Action executes its logic properly in isolation. When you do this, you may mock or stub out services the Action implementation needs that are expensive to initialize. You can also verify there that the action puts everything in the flow or request scope it was expected to (to meet its contract with the view it is prepping for display, for example).

Second, you can attach one or more FlowExecutionListeners to the flow execution at start time within your test code, which will allow you to receive a callback on each state transition (among other points). It is recommended you extend org.springframework.webflow.execution.FlowExecutionListenerAdapter and only override the callback methods you are interested in.
Parameters:
  eventId - the event that occured
Parameters:
  context - the external context providing information about thecaller's environment, used by the flow execution during the signal eventoperation the view selection that was made, returned once control isreturned to the client (occurs when the flow enters a view state, or anend state)
throws:
  FlowExecutionException - if an exception was thrown within a stateof the resumed flow execution during event processing

Convenience operation that starts the execution with:

• no input attributes
• an empty ExternalContext with no environmental request parameters set

Convenience operation that starts the execution with:

• the specified input attributes, eligible for mapping by the root flow
• an empty ExternalContext with no environmental request parameters set

This is the most flexible of the start methods. It allows you to specify:

1. a map of input attributes to pass to the flow execution, eligible for mapping by the root flow definition
2. an external context that provides the flow execution being tested access to the calling environment for this request