Re: [Springframework-developer] Spring Web Flow

[Colin S. <col...@ex...>]

Mocks were around, in static form, quite a while before dynamic mocks 
ever started being used. The latter really depends on the existence of 
the JDK proxy (or something similar such as cglib). So the name mock is 
appropriate even for a static classes.

While 'Stub' is used sometimes for the same purpose, I personally like 
the name Mock better when it's clear that the class in question is just 
going to be used for testing...

Colin

Keith Donald wrote:

> 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
>