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

[Rod J. <rod...@in...>]

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, although
I'd really prefer a dedicated tree there as well. I'm sure that other stu=
ff
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] Testi=
ng
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:

>Matt, everybody,
>
>Essentially, the Servlet API mocks in Spring's test directory are just
there because the MockObjects (http://www.mockobjects.com) Servlet API mo=
cks
are so inconvenient to use. The current Spring-provided Servlet API mocks
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 lo=
se
:-)
>
>So on that occasion, I've reworked those mocks today, making them
significantly more complete than before, and ready for getting included i=
n
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 th=
en.
The test directory (where they currently reside) is no appropriate place,=
 as
it is about testing the framework rather than providing infrastructure
classes.
>
>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 specifically
provided to ease testing of Spring web contexts (like
XmlWebApplicationContext or StaticWebApplicationContext that need a
ServletContext) and controllers (the Controller.handleRequest method need=
s
an HttpServletRequest and an HttpServletResponse). Including them in the
standard distribution would also indicate our strong focus on testability.
>
>The new MockServletContext implementation uses the
org.springframework.core.io.Resource API for resource loading, to allow f=
or
ServletContext.getResourceAsStream from any resource base. So partly, the
mock implementations depend on low-level Spring API. We could of course k=
eep
the mocks in a separate part of the Spring CVS, but it's just about a cou=
ple
of classes, 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 Str=
uts
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 into t=
he
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 interfa=
ces
that can conveniently be mocked in a dynamic fashion with EasyMock. There
are just two exceptions, as far I see: Our SimpleNamingContext stuff ease=
s
custom JNDI environments, and the newly refined set of Servlet API mocks
allows for convenient testing of Spring web MVC (and web contexts).
>
>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
preferable 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,
parameters, attributes).
>
>What does everybody think? Does anyone mind including those polished
Servlet API mocks in the main Spring codebase, already for 1.0.2? Any
suggestions for alternatives?
>
>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:
>
>
>
>>Matt,
>>
>>I just tried using MockHttpServletRequest and MockHttpServletResponse
>>from MockObjects with a Spring FormController. Unfortunately, those
>>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 FormControllers
>>
>>
>>
>>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
>>
>>



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer