Menu
▾
▴
Re: [Springframework-developer] Re: [Springframework-user] Testing Controllers and FormControllers
|
From: Dmitriy K. <dko...@ru...> - 2004-04-27 21:27:55
|
How about "mock" CVS tree and spring-mock.jar distribution? Regards, Dmitriy. Rod Johnson wrote: >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_id?66&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
