Re: [Springframework-developer] Testing Controllers and FormControllers

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Juergen,

I would vote for org.springframework.mock.* package names.

Regards,
Dmitriy.

jürgen höller [werk3AT] wrote:
> 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 anyway: They are mainly used in our framework test suite. And whoever uses them 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 testing 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.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.
> 
> 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, 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.
> 
> 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] Testing
> 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ürgen höller [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 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) !=
>>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ürgen höller [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ürgen höller [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/?cpg297
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> 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_id66&op=ick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> -------------------------------------------------------
> 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_id66&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer