Vishwanath Krishnamurthi's blog

A blog on Java EE, clean code, open source and TDD

Using mockito to unit test Spring Webflow (2)

with one comment

This is as a continuation to this post on unit testing flows in Spring Webflow.

I wish to start testing  from an intermediate state (other than start state )

Sure, No Problem.

public void  discountCheck()
//Now we should be in viewDiscountDetails state. Can fire any transition defined for this state.

So the only thing to watch in the above snippet is that, if  you are starting your test from an intermediate state,  set the state to start with and then use resumeFlow()  instead of using startFlow() .

Also note that the <on-entry> …. </on-entry> expressions of  ‘viewDiscountsDetails’ state are not evaluated when the test is executed. I think that is because by setting the currentState, we have told SWF, that the state has already been entered. (So it wouldn’t bother with the on-entry expressions 😀 )

How about stubbing of some scoped attributes ?

We could simply add this line in the test.

this.getFlowScope().put("productSelected", new Car());

But note that this line is valid only after you’ve started a flow.. Hence the following would result in an error, since there’s no active flow.

this.getFlowScope().put("productSelected", new Car());

Asserting  for an action-state  doesn’t work

Once a flow is started, it goes through the decision-states or action-states and pauses its execution only in a view-state. Hence asserting a current state to be an action state or a decision state would never pass.

Instead, we can use  the verify method in mockito to test if a method in the action was indeed invoked.

   verify(mockedBazService.paymentProcess(accountInfo)); // verify an action method was executed
  assertCurrentStateEquals("paymentSuccessfulView"); //assert execution has paused in this view state

Switching to some general talk, the question we’d have while writing these unit tests is

What could SWF unit-testing expose ?

I haven’t tried with all the below points, but looks like it is all possible.

  • Ensure validators bound were actually called
  • Ensure exception handler catches exceptions as expected
  • Ensure a matching transition does exist 
  • Ensure the traversal path was as expected 
  • Ensure a model is bound to a view correctly : assertModelAttributeNotNull()
  • Help us in the use of right attributes in the right scope: getRequired<XXX>Attribute() asserts that an attribute is present in that scope. Ensure it is present / cleared etc. Probably the best way to understand the use of flashScope, viewScope etc that SWF provides. 
  • Ensure a view was resolved as expected
  • Simulate a refresh and run some asserts
I wish to trace the flow better / I would like to make some hacky workarounds:
Its pretty easy to attach a listener to the flow using
this.setFlowExecutionListener( new MyListener());
where MyListener is a class that extends FlowExecutionListenerAdapter and overrides the required methods.
Well then, I’ve typed enough.. Time I get back to my IDE. Enjoy your coding ! and do let me know of any helpful SWF testing tips. 😉

Written by Vishwanath Krishnamurthi

July 21, 2011 at 5:50 pm

One Response

Subscribe to comments with RSS.

  1. Using mockito to unit test Spring Webflow (2) « Vishwanath Krishnamurthi’s blog…

    Thank you for submitting this cool story – Trackback from JavaPins…


    July 18, 2012 at 8:23 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: