Menu
▾
▴
springframework-developer
|
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 |
|
From: Michael S. <mi...@sc...> - 2005-03-21 23:45:51
|
On Tuesday 22 March 2005 00:07, Keith Donald wrote: > 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"? For those who haven't seen the article before or don't remember the=20 details: http://www.martinfowler.com/articles/mocksArentStubs.html <quote> In the view of the mock community, the key difference with mocks is the=20 expectation setting mechanism where you test which methods were called=20 on the mock. Mockists often refer to a mock object that just returns=20 values as 'just a stub'. </quote> Also, as Fowler notes, the common mock object libraries do a good job at=20 creating stubs, too. Thus, whether an object is a mock or a stub isn't so much a matter of=20 its class, but rather of how it is used. Some objects are too dumb to=20 be used as mocks, therefore it's straightforward to name their classes=20 WhateverStub. A class whose instances can be used for interaction-based=20 testing -- but don't have to -- deserves a Mock name. Just my 2=A2, Michael --=20 Michael Schuerig All good people read good books mailto:mi...@sc... Now your conscience is clear http://www.schuerig.de/michael/ --Tanita Tikaram, Twist In My Sobriety |
|
From: Colin S. <col...@ex...> - 2005-03-22 15:21:27
|
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 > |
