Re: [Springframework-developer] Testing Controllers and FormControllers

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

+1: spring-mock.jar
+1: separate mock tree
+1: org.springframework.mock.* subpackages

Thomas


jürgen höller [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, because 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ürgen höller [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 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=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
>
>
>
>  
>