Menu
▾
▴
Re: [Springframework-developer] Testing Controllers and FormControllers
|
From: <jue...@we...> - 2004-04-28 12:38:16
|
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: >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) = !=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: > > > >>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=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 >> >> ------------------------------------------------------- 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/?cpg=12297 _______________________________________________ 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.=20 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 |
