Re: [Springframework-developer] Testing Controllers and FormControllers

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

+1 on org.springframework.mock

j=FCrgen h=F6ller [werk3AT] wrote:

>Works nicely: spring-mock.jar is currently 26 KB, including the JNDI and=
 the web mocks. The size of spring.jar went down from 973 KB to 956 KB, b=
ecause of the JNDI mocks not being included there anymore.
>
>In total, I completely agree that a separate mock tree makes sense. The =
only remaining question is the package naming: I tend to prefer the "org.=
springframework.mock" subpackages, for having a clear package subtree in =
the "mock" directory.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of j=FCrgen h=F6ller [werk3AT]
>Sent: Wednesday, April 28, 2004 2:32 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Testing Controllers and
>FormControllers
>
>
>If we move them to a separate JAR and separate tree, the mock classes in=
 the jndi.support package more or less have to join them for consistency =
reasons. I prefer the name "spring-mock.jar" to "spring-test.jar", as the=
 latter is already used as directory name for the test suite.
>
>Given our decoupling from JNDI, I doubt that anyone those JNDI mocks any=
way: They are mainly used in our framework test suite. And whoever uses t=
hem in a test suite can seamlessly adapt the package name.
>
>So this looks like:
>
>* a new "mock" directory (alongside "docs", "src", etc), containing the =
mock sources (without "src" subdirectory, as there is not much point in t=
esting mocks, therefore there won't be a "test" subdirectory there)
>
>* a "spring-mock.jar", generated from the "mock" directory by the build =
script, shipped in the "dist" directory of our distribution
>
>The remaining question is: How to name the packages there? org.springfra=
mework.jndi.mock / org.springframework.web.mock or org.springframework.mo=
ck.jndi / org.springframework.mock.web? I guess the latter is more approp=
riate, given that they are in a separate source tree.
>
>As a side note: I doubt that those mocks will expand significantly, but =
I still see the point in keeping them in a dedicated tree.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rod Johnson
>Sent: Tuesday, April 27, 2004 11:13 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Re: [Springframework-user]
>Testing Controllers and FormControllers
>
>
>Thanks for the cleaning up: they needed it. However, I feel uneasy about
>these classes being included in spring.jar. I would like to see them in =
a
>spring-test.jar.
>
>I don't particularly object to them going in the main /src tree, althoug=
h
>I'd really prefer a dedicated tree there as well. I'm sure that other st=
uff
>will join them in such a new tree.
>
>Rgds,
>Rod
>
>----- Original Message -----
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Cc: <spr...@li...>
>Sent: Tuesday, April 27, 2004 9:30 PM
>Subject: Re: [Springframework-developer] Re: [Springframework-user] Test=
ing
>Controllers and FormControllers
>
>
>I'm ok with including these in Spring; if people feel they are too big,
>they could be a spring-test add-on jar, that's not even included in the
>main spring.jar which normally included all the optional stuff. That
>makes some sense since this is for testing.
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
> =20
>
>>Matt, everybody,
>>
>>Essentially, the Servlet API mocks in Spring's test directory are just
>>   =20
>>
>there because the MockObjects (http://www.mockobjects.com) Servlet API m=
ocks
>are so inconvenient to use. The current Spring-provided Servlet API mock=
s
>are by no means in a polished state, though: They're just good enough fo=
r
>being used within the framework test suite. They'd need some serious
>refinement for making them public - after all, we have a reputation to l=
ose
>:-)
> =20
>
>>So on that occasion, I've reworked those mocks today, making them
>>   =20
>>
>significantly more complete than before, and ready for getting included =
in
>the Spring distribution. The question is: Where to include them? I'd lik=
e to
>include them in the main Spring sources, in a org.springframework.web.mo=
ck
>package: They would naturally be part of spring.jar and spring-web.jar t=
hen.
>The test directory (where they currently reside) is no appropriate place=
, as
>it is about testing the framework rather than providing infrastructure
>classes.
> =20
>
>>While it isn't in general appropriate to include mocks in the main Spri=
ng
>>   =20
>>
>codebase, I guess this is a different case: Those mocks are specifically
>provided to ease testing of Spring web contexts (like
>XmlWebApplicationContext or StaticWebApplicationContext that need a
>ServletContext) and controllers (the Controller.handleRequest method nee=
ds
>an HttpServletRequest and an HttpServletResponse). Including them in the
>standard distribution would also indicate our strong focus on testabilit=
y.
> =20
>
>>The new MockServletContext implementation uses the
>>   =20
>>
>org.springframework.core.io.Resource API for resource loading, to allow =
for
>ServletContext.getResourceAsStream from any resource base. So partly, th=
e
>mock implementations depend on low-level Spring API. We could of course =
keep
>the mocks in a separate part of the Spring CVS, but it's just about a co=
uple
>of classes, thus hardly worth a separate source tree.
> =20
>
>>IMO, the main concern regarding additions to the main Spring codebase i=
s
>>   =20
>>
>whether those additions can potentially grow significantly: While Keith'=
s
>rules API in the sandbox has definite potential there (so had Ben Alex'
>security framework that became the Acegi Security System), the recent St=
ruts
>support classes and those Servlet API mocks will at best see slight
>refinements but certainly not exponential growth. So the former seems li=
ke a
>candidate for a separate module to me, while the latter should fit into =
the
>main Spring codebase.
> =20
>
>>An important point to consider is that there are simply no mocks necess=
ary
>>   =20
>>
>for testing most parts of a typical Spring app, respectively just interf=
aces
>that can conveniently be mocked in a dynamic fashion with EasyMock. Ther=
e
>are just two exceptions, as far I see: Our SimpleNamingContext stuff eas=
es
>custom JNDI environments, and the newly refined set of Servlet API mocks
>allows for convenient testing of Spring web MVC (and web contexts).
> =20
>
>>Mocking an EJB container is next to impossible, so that's not worth fur=
ther
>>   =20
>>
>consideration. JDBC can quite nicely be mocked with EasyMock; it's
>preferable to use the JdbcOperations interface as far as possible, thoug=
h.
>Same for a Hibernate Session, with HibernateOperations being preferable.
>It's more or less just the Servlet API that's really tedious to mock wit=
h
>EasyMock, due to all those interdependent methods (e.g. URL paths,
>parameters, attributes).
> =20
>
>>What does everybody think? Does anyone mind including those polished
>>   =20
>>
>Servlet API mocks in the main Spring codebase, already for 1.0.2? Any
>suggestions for alternatives?
> =20
>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf Of
>>Matt Raible
>>Sent: Saturday, April 24, 2004 2:02 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-user] Testing Controllers and
>>FormControllers
>>
>>
>>I use StrutsTestCase (http://strutstestcase.sf.net), which allows you
>>to write very little code to test an Action.  Here is a simple example
>>of testing an "execute" method:
>>
>>package org.appfuse.webapp.action;
>>
>>import servletunit.struts.CactusStrutsTestCase;
>>import org.appfuse.Constants;
>>
>>public class PersonActionTest extends CactusStrutsTestCase {
>>
>>   public PersonActionTest(String name) {
>>       super(name);
>>   }
>>
>>   public void testExecute() {
>>       // test execute method
>>       setRequestPathInfo("/editPerson");
>>       addRequestParameter("id", "1");
>>       actionPerform();
>>       verifyNoActionErrors();
>>        assertNotNull(getRequest().getAttribute(Constants.PERSON_KEY));
>>    }
>>
>>    public static void main(String[] args) {
>>        junit.textui.TestRunner.run(PersonActionTest.class);
>>    }
>>}
>>
>>Since CactusStrutsTestCase extends from Cactus, I can also use Cactus's
>>FormAuthentication support to mimic container-managed authentication.
>>
>>To test a "Save" is also pretty simple.
>>
>>    public void testSave() throws Exception {
>>        setRequestPathInfo("/editPerson");
>>        addRequestParameter("action", "Edit");
>>        addRequestParameter("id", "1");
>>
>>        actionPerform();
>>
>>        assertTrue(getRequest().getAttribute(Constants.PERSON_KEY) !=3D
>>null);
>>
>>        setRequestPathInfo("/savePerson");
>>        addRequestParameter("action", "Save");
>>        actionPerform();
>>        verifyForward("edit");
>>        verifyNoActionErrors();
>>    }
>>
>>I think you have something similar to this with the Mock Object you're
>>using in Spring.  It just needs to be packaged up as a JAR.  I'll be
>>more than happy to write up some documentation on how to use it.
>>
>>Matt
>>
>>
>>On Apr 24, 2004, at 4:27 AM, j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>
>>
>>   =20
>>
>>>Matt,
>>>
>>>I just tried using MockHttpServletRequest and MockHttpServletResponse
>>>     =20
>>>
>>>from MockObjects with a Spring FormController. Unfortunately, those
>>   =20
>>
>>>MockObjects mocks are really not well-suited for testing here, as it's
>>>so much hassle to setup any kind of HttpServletRequest method access.
>>>What request/response mocks do you use for testing Struts Actions?
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im Auftrag von
>>>j=FCrgen h=F6ller [werk3AT]
>>>Gesendet: Sa 24.04.2004 10:57
>>>An: spr...@li...
>>>Betreff: Re: [Springframework-user] Testing Controllers and
>>>FormControllers
>>>
>>>
>>>
>>>I don't see much difference between testing Controllers and
>>>FormControllers: Both share the same "ModelAndView
>>>handleRequest(HttpServletRequest, HttpServletResponse)" method that
>>>you need to invoke for testing. As of 1.0.1, you shouldn't need a
>>>ServletContext mock anymore (except when actually accessing the
>>>ServletContext), so all you need are HttpServletRequest and
>>>HttpServletResponse mocks. The mocks provided by the MockObjects
>>>project should be fine for this.
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im Auftrag von
>>>Matt Raible
>>>Gesendet: Fr 23.04.2004 20:48
>>>An: spr...@li...
>>>Betreff: [Springframework-user] Testing Controllers and FormController=
s
>>>
>>>
>>>
>>>I've found it pretty simple to test Controllers, but FormControllers
>>>are
>>>a different story.  From looking at the FormControllerTestSuite (URL
>>>below), as well as many other Spring tests, it seems that a lot of
>>>internal mocks are used to test this stuff.
>>>
>>>So my question is - what do you recommend for the average Spring MVC
>>>person?  What is the strategy we should be using to test our
>>>controllers?  Should we be using the Mocks that Spring provides?  This
>>>would certainly make things easier.  If we're supposed to do that - is
>>>it possible to get these mocks distributed in a JAR?
>>>
>>>Thanks,
>>>
>>>Matt
>>>
>>>http://monkeymachine.co.uk/spring/xref-test/org/springframework/web/
>>>serv
>>>let/mvc/FormControllerTestSuite.html
>>>     =20
>>>