Menu
▾
▴
Re: [Springframework-developer] Testing Controllers and FormControllers
|
From: <jue...@we...> - 2004-04-28 21:46:14
|
BTW, I've already committed the factored-out "mock" tree, including = adapted build scripts etc. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Mi 28.04.2004 21:32 An: spr...@li... Betreff: Re: [Springframework-developer] Testing Controllers and = FormControllers The classes currently slated to go there are external classes (to Spring), in any case. For mocks for Spring internal classes (if and when they appear), they may belong in the mocked class's package, and stored under the existing test tree or the mock tree as appropriate. Alef Arendsen wrote: >+1 on the org.springframework.mock.* packages, > >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 > > >=20 > >>-----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 >> >>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=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 = 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=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 = 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 >>:-) >> =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 = 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. >> =20 >> >>>While it isn't in general appropriate to include mocks in the main = Spring >>> =20 >>> >>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. >> =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, = 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. >> =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 = like >>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. = 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). >> =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, = 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). >> =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 = 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 >>>> ------------------------------------------------------- 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 |
