Re: [Springframework-developer] Re: [Springframework-user] Testing Controllers and FormControllers

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

I'm ok with including these in Spring; if people feel they are too big,=20
they could be a spring-test add-on jar, that's not even included in the=20
main spring.jar which normally included all the optional stuff. That=20
makes some sense since this is for testing.

j=FCrgen h=F6ller [werk3AT] wrote:

>Matt, everybody,=20
>
>Essentially, the Servlet API mocks in Spring's test directory are just t=
here because the MockObjects (http://www.mockobjects.com) Servlet API moc=
ks are so inconvenient to use. The current Spring-provided Servlet API mo=
cks are by no means in a polished state, though: They're just good enough=
 for 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 :-)
>
>So on that occasion, I've reworked those mocks today, making them signif=
icantly more complete than before, and ready for getting included in the =
Spring distribution. The question is: Where to include them? I'd like to =
include them in the main Spring sources, in a org.springframework.web.moc=
k package: They would naturally be part of spring.jar and spring-web.jar =
then. The test directory (where they currently reside) is no appropriate =
place, as it is about testing the framework rather than providing infrast=
ructure classes.=20
>
>While it isn't in general appropriate to include mocks in the main Sprin=
g codebase, I guess this is a different case: Those mocks are specificall=
y provided to ease testing of Spring web contexts (like XmlWebApplication=
Context or StaticWebApplicationContext that need a ServletContext) and co=
ntrollers (the Controller.handleRequest method needs an HttpServletReques=
t and an HttpServletResponse). Including them in the standard distributio=
n would also indicate our strong focus on testability.
>
>The new MockServletContext implementation uses the org.springframework.c=
ore.io.Resource API for resource loading, to allow for ServletContext.get=
ResourceAsStream from any resource base. So partly, the mock implementati=
ons 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 couple of classe=
s, thus hardly worth a separate source tree.
>
>IMO, the main concern regarding additions to the main Spring codebase is=
 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 lik=
e a candidate for a separate module to me, while the latter should fit in=
to the main Spring codebase.
>
>An important point to consider is that there are simply no mocks necessa=
ry for testing most parts of a typical Spring app, respectively just inte=
rfaces that can conveniently be mocked in a dynamic fashion with EasyMock=
. There are just two exceptions, as far I see: Our SimpleNamingContext st=
uff eases custom JNDI environments, and the newly refined set of Servlet =
API mocks allows for convenient testing of Spring web MVC (and web contex=
ts).
>
>Mocking an EJB container is next to impossible, so that's not worth furt=
her consideration. JDBC can quite nicely be mocked with EasyMock; it's pr=
eferable to use the JdbcOperations interface as far as possible, though. =
Same for a Hibernate Session, with HibernateOperations being preferable. =
It's more or less just the Servlet API that's really tedious to mock with=
 EasyMock, due to all those interdependent methods (e.g. URL paths, param=
eters, attributes).
>
>What does everybody think? Does anyone mind including those polished Ser=
vlet API mocks in the main Spring codebase, already for 1.0.2? Any sugges=
tions for alternatives?
>
>Juergen
>
>
>-----Original Message-----=20
>From: spr...@li...=20
>[mailto:spr...@li...]On Behalf Of=20
>Matt Raible=20
>Sent: Saturday, April 24, 2004 2:02 PM=20
>To: spr...@li...=20
>Subject: Re: [Springframework-user] Testing Controllers and=20
>FormControllers=20
>
>
>I use StrutsTestCase (http://strutstestcase.sf.net), which allows you =20
>to write very little code to test an Action.  Here is a simple example =20
>of testing an "execute" method:=20
>
>package org.appfuse.webapp.action;=20
>
>import servletunit.struts.CactusStrutsTestCase;=20
>import org.appfuse.Constants;=20
>
>public class PersonActionTest extends CactusStrutsTestCase {=20
>    =20
>    public PersonActionTest(String name) {=20
>        super(name);=20
>    }=20
>
>    public void testExecute() {=20
>        // test execute method=20
>        setRequestPathInfo("/editPerson");=20
>        addRequestParameter("id", "1");=20
>        actionPerform();=20
>        verifyNoActionErrors();=20
>         assertNotNull(getRequest().getAttribute(Constants.PERSON_KEY));=
=20
>     }=20
>
>     public static void main(String[] args) {=20
>         junit.textui.TestRunner.run(PersonActionTest.class);=20
>     }=20
>}=20
>
>Since CactusStrutsTestCase extends from Cactus, I can also use Cactus's =
=20
>FormAuthentication support to mimic container-managed authentication.=20
>
>To test a "Save" is also pretty simple.=20
>
>     public void testSave() throws Exception {=20
>         setRequestPathInfo("/editPerson");=20
>         addRequestParameter("action", "Edit");=20
>         addRequestParameter("id", "1");=20
>
>         actionPerform();=20
>
>         assertTrue(getRequest().getAttribute(Constants.PERSON_KEY) !=3D=
 =20
>null);=20
>
>         setRequestPathInfo("/savePerson");=20
>         addRequestParameter("action", "Save");=20
>         actionPerform();=20
>         verifyForward("edit");=20
>         verifyNoActionErrors();=20
>     }=20
>
>I think you have something similar to this with the Mock Object you're =20
>using in Spring.  It just needs to be packaged up as a JAR.  I'll be =20
>more than happy to write up some documentation on how to use it.=20
>
>Matt=20
>
>
>On Apr 24, 2004, at 4:27 AM, j=FCrgen h=F6ller [werk3AT] wrote:=20
>
> =20
>
>>Matt,=20
>>
>>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 =
=20
>>so much hassle to setup any kind of HttpServletRequest method access. =20
>>What request/response mocks do you use for testing Struts Actions?=20
>>
>>Juergen=20
>>
>>
>>________________________________=20
>>
>>Von: spr...@li... im Auftrag von =20
>>j=FCrgen h=F6ller [werk3AT]=20
>>Gesendet: Sa 24.04.2004 10:57=20
>>An: spr...@li...=20
>>Betreff: Re: [Springframework-user] Testing Controllers and =20
>>FormControllers=20
>>
>>
>>
>>I don't see much difference between testing Controllers and =20
>>FormControllers: Both share the same "ModelAndView =20
>>handleRequest(HttpServletRequest, HttpServletResponse)" method that =20
>>you need to invoke for testing. As of 1.0.1, you shouldn't need a =20
>>ServletContext mock anymore (except when actually accessing the =20
>>ServletContext), so all you need are HttpServletRequest and =20
>>HttpServletResponse mocks. The mocks provided by the MockObjects =20
>>project should be fine for this.=20
>>
>>Juergen=20
>>
>>
>>________________________________=20
>>
>>Von: spr...@li... im Auftrag von =20
>>Matt Raible=20
>>Gesendet: Fr 23.04.2004 20:48=20
>>An: spr...@li...=20
>>Betreff: [Springframework-user] Testing Controllers and FormControllers=
=20
>>
>>
>>
>>I've found it pretty simple to test Controllers, but FormControllers =20
>>are=20
>>a different story.  From looking at the FormControllerTestSuite (URL=20
>>below), as well as many other Spring tests, it seems that a lot of=20
>>internal mocks are used to test this stuff.=20
>>
>>So my question is - what do you recommend for the average Spring MVC=20
>>person?  What is the strategy we should be using to test our=20
>>controllers?  Should we be using the Mocks that Spring provides?  This=20
>>would certainly make things easier.  If we're supposed to do that - is=20
>>it possible to get these mocks distributed in a JAR?=20
>>
>>Thanks,=20
>>
>>Matt=20
>>
>>http://monkeymachine.co.uk/spring/xref-test/org/springframework/web/=20
>>serv=20
>>let/mvc/FormControllerTestSuite.html=20
>>   =20
>>