Menu
▾
▴
Re: [Springframework-developer] Testing Controllers and FormControllers
|
From: Colin S. <col...@ex...> - 2004-04-28 19:32:24
|
The classes currently slated to go there are external classes (to=20 Spring), in any case. For mocks for Spring internal classes (if and when they appear), they=20 may belong in the mocked class's package, and stored under the existing=20 test tree or the mock tree as appropriate. Alef Arendsen wrote: >+1 on the org.springframework.mock.* packages,=20 > >although you loose the possibility of having access to package visible s= tuff >when not putting the mocks in the same package as the stuff they mock... > >Alef > > > =20 > >>-----Original Message----- >>From: spr...@li... >>[mailto:spr...@li...] On Behal= f >>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 >> >>Works nicely: spring-mock.jar is currently 26 KB, including the JNDI an= d >>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 subt= ree >>in the "mock" directory. >> >>Juergen >> >> >>-----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 >> >> >>If we move them to a separate JAR and separate tree, the mock classes i= n >>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 t= he >>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 u= ses >>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 t= he >>latter is more appropriate, given that they are in a separate source tr= ee. >> >>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 abou= t >>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, althou= gh >>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=FCrgen h=F6ller [werk3AT] wrote: >> >> =20 >> >>>Matt, everybody, >>> >>>Essentially, the Servlet API mocks in Spring's test directory are just >>> =20 >>> >>there because the MockObjects (http://www.mockobjects.com) Servlet API >>mocks >>are so inconvenient to use. The current Spring-provided Servlet API moc= ks >>are by no means in a polished state, though: They're just good enough f= or >>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 >>:-) >> =20 >> >>>So on that occasion, I've reworked those mocks today, making them >>> =20 >>> >>significantly more complete than before, and ready for getting included= in >>the Spring distribution. The question is: Where to include them? I'd li= ke >>to >>include them in the main Spring sources, in a org.springframework.web.m= ock >>package: They would naturally be part of spring.jar and spring-web.jar >>then. >>The test directory (where they currently reside) is no appropriate plac= e, >>as >>it is about testing the framework rather than providing infrastructure >>classes. >> =20 >> >>>While it isn't in general appropriate to include mocks in the main Spr= ing >>> =20 >>> >>codebase, I guess this is a different case: Those mocks are specificall= y >>provided to ease testing of Spring web contexts (like >>XmlWebApplicationContext or StaticWebApplicationContext that need a >>ServletContext) and controllers (the Controller.handleRequest method ne= eds >>an HttpServletRequest and an HttpServletResponse). Including them in th= e >>standard distribution would also indicate our strong focus on testabili= ty. >> =20 >> >>>The new MockServletContext implementation uses the >>> =20 >>> >>org.springframework.core.io.Resource API for resource loading, to allow >>for >>ServletContext.getResourceAsStream from any resource base. So partly, t= he >>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. >> =20 >> >>>IMO, the main concern regarding additions to the main Spring codebase = is >>> =20 >>> >>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 l= ike >>a >>candidate for a separate module to me, while the latter should fit into >>the >>main Spring codebase. >> =20 >> >>>An important point to consider is that there are simply no mocks >>> =20 >>> >>necessary >>for testing most parts of a typical Spring app, respectively just >>interfaces >>that can conveniently be mocked in a dynamic fashion with EasyMock. The= re >>are just two exceptions, as far I see: Our SimpleNamingContext stuff ea= ses >>custom JNDI environments, and the newly refined set of Servlet API mock= s >>allows for convenient testing of Spring web MVC (and web contexts). >> =20 >> >>>Mocking an EJB container is next to impossible, so that's not worth >>> =20 >>> >>further >>consideration. JDBC can quite nicely be mocked with EasyMock; it's >>preferable to use the JdbcOperations interface as far as possible, thou= gh. >>Same for a Hibernate Session, with HibernateOperations being preferable= . >>It's more or less just the Servlet API that's really tedious to mock wi= th >>EasyMock, due to all those interdependent methods (e.g. URL paths, >>parameters, attributes). >> =20 >> >>>What does everybody think? Does anyone mind including those polished >>> =20 >>> >>Servlet API mocks in the main Spring codebase, already for 1.0.2? Any >>suggestions for alternatives? >> =20 >> >>>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: >>> >>> >>> >>> =20 >>> >>>>Matt, >>>> >>>>I just tried using MockHttpServletRequest and MockHttpServletResponse >>>> =20 >>>> >>>>from MockObjects with a Spring FormController. Unfortunately, those >>> =20 >>> >>>>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 FormControlle= rs >>>> >>>> >>>> >>>>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? Thi= s >>>>would certainly make things easier. If we're supposed to do that - i= s >>>>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 >>>> |
