RE: [Springframework-developer] Spring Web Flow

[Keith D. <ke...@in...>]

To bottom line it, decoupling web.flow from the servlet API lets flows be
used in other environments, like portlets, JSF, Tapestry, etc.  There was a
lot of demand for this expressed at TSSJS, and it really does make sense.

 

Having the request context provides a more features/flexibility as well, as
you'll see once you start working with it.  It doesn't any introduction
complexity (it's arguably considerably simpler now, as Acitions deal with
one argument at a consistent level of abstraction, vs. three arguments that
are at different levels of abstraction.)

 

I agree you do have a point about Actions being more difficult to unit test,
as previously you could just use the MockHttpRequest and MockHttpResponse
objects.  A stub RequestContext implementation make sense (I don't see why
you'd need to stub out other stuff like Scope since they're very simple
objects, though.)

 

I'll give it a go writing a unit test for one of the Phonebook actions and
see about factoring out a MockRequestContext.  True standalone unit testing
of Actions really isn't possible without the mock as I see it, as yes, the
InternalRequestContext implementation assumes you're executing a request in
the context of an ongoing flow execution, which is really more like
integration testing (taking into account the flow, the states, etc.)

 

Keith

 

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Will Butler
Sent: Monday, March 21, 2005 5:34 PM
To: spr...@li...
Subject: [Springframework-developer] Spring Web Flow

 

All,

 

We have been using the Ervacon version of Spring Web Flow since version 0.7,
and we are now attempting to migrate to the new code in the Spring sandbox.
In the process, however, I noticed that the decoupling of actions from the
request/response has made them more difficult to test. Creating a
RequestContext requires an Event and a FlowExecutionStack which requires...
Anyway, I realize that we could create a Mock of the RequestContext, but
this also requires that child elements like Scope need to be mocked out as
well. What is the motivation behind the additional layers of abstraction and
why are they necessary? Does anyone best practices and/or examples for unit
testing actions in the new design?

 

Thanks,

 

Will Butler