|
From: Keith D. <ke...@in...> - 2005-03-21 23:07:10
|
This does bring up a terminology issue, I think: e.g. why do we call MockHttpRequest what it is and not "StubHttpRequest"? I mean what I'm about to create I would consider a Stub (no need for dynamic mocks or anything), but we don't really use that term anywhere for any classes in spring-test that I'm aware of. What do you guys think, when should we use the term "Stub" and when should we use "Mock"? Keith _____ From: Keith Donald [mailto:ke...@in...] Sent: Monday, March 21, 2005 5:57 PM To: 'spr...@li...' Subject: RE: [Springframework-developer] Spring Web Flow 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 |