RE: [Springframework-developer] Testing Controllers and FormControllers

[Alef A. <al...@jt...>]

+1 on the org.springframework.mock.* packages,=20

although you loose the possibility of having access to package visible =
stuff
when not putting the mocks in the same package as the stuff they mock...

Alef


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of j=FCrgen h=F6ller [werk3AT]
> Sent: Wednesday, April 28, 2004 2:57 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Testing Controllers and
> FormControllers
>=20
> 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,
> because of the JNDI mocks not being included there anymore.
>=20
> 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.
>=20
> Juergen
>=20
>=20
> -----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
>=20
>=20
> 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.
>=20
> Given our decoupling from JNDI, I doubt that anyone those JNDI mocks
> anyway: They are mainly used in our framework test suite. And whoever =
uses
> them in a test suite can seamlessly adapt the package name.
>=20
> So this looks like:
>=20
> * a new "mock" directory (alongside "docs", "src", etc), containing =
the
> mock sources (without "src" subdirectory, as there is not much point =
in
> testing mocks, therefore there won't be a "test" subdirectory there)
>=20
> * a "spring-mock.jar", generated from the "mock" directory by the =
build
> script, shipped in the "dist" directory of our distribution
>=20
> The remaining question is: How to name the packages there?
> org.springframework.jndi.mock / org.springframework.web.mock or
> org.springframework.mock.jndi / org.springframework.mock.web? I guess =
the
> latter is more appropriate, given that they are in a separate source =
tree.
>=20
> 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.
>=20
> Juergen
>=20
>=20
> -----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
>=20
>=20
> 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.
>=20
> 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
> stuff
> will join them in such a new tree.
>=20
> Rgds,
> Rod
>=20
> ----- 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]
> Testing
> Controllers and FormControllers
>=20
>=20
> 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.
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
>=20
> >Matt, everybody,
> >
> >Essentially, the Servlet API mocks in Spring's test directory are =
just
> there because the MockObjects (http://www.mockobjects.com) Servlet API
> mocks
> 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
> lose
> :-)
> >
> >So on that occasion, I've reworked those mocks today, making them
> significantly 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.mock
> 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 infrastructure
> classes.
> >
> >While it isn't in general appropriate to include mocks in the main =
Spring
> 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 =
needs
> 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
> for
> ServletContext.getResourceAsStream from any resource base. So partly, =
the
> 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
> couple
> 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
> Struts
> support classes and those Servlet API mocks will at best see slight
> refinements but certainly not exponential growth. So the former seems =
like
> a
> candidate for a separate module to me, while the latter should fit =
into
> the
> main Spring codebase.
> >
> >An important point to consider is that there are simply no mocks
> necessary
> for testing most parts of a typical Spring app, respectively just
> interfaces
> that can conveniently be mocked in a dynamic fashion with EasyMock. =
There
> are just two exceptions, as far I see: Our SimpleNamingContext stuff =
eases
> 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
> further
> 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
> >>
> >>
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer