Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-04-27 17:58:44
|
Matt, everybody,=20 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.=20 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-----=20 From: spr...@li...=20 [mailto:spr...@li...]On Behalf Of=20 Matt Raible=20 Sent: Saturday, April 24, 2004 2:02 PM=20 To: spr...@li...=20 Subject: Re: [Springframework-user] Testing Controllers and=20 FormControllers=20 I use StrutsTestCase (http://strutstestcase.sf.net), which allows you =20 to write very little code to test an Action. Here is a simple example =20 of testing an "execute" method:=20 package org.appfuse.webapp.action;=20 import servletunit.struts.CactusStrutsTestCase;=20 import org.appfuse.Constants;=20 public class PersonActionTest extends CactusStrutsTestCase {=20 =20 public PersonActionTest(String name) {=20 super(name);=20 }=20 public void testExecute() {=20 // test execute method=20 setRequestPathInfo("/editPerson");=20 addRequestParameter("id", "1");=20 actionPerform();=20 verifyNoActionErrors();=20 assertNotNull(getRequest().getAttribute(Constants.PERSON_KEY)); = }=20 public static void main(String[] args) {=20 junit.textui.TestRunner.run(PersonActionTest.class);=20 }=20 }=20 Since CactusStrutsTestCase extends from Cactus, I can also use Cactus's = FormAuthentication support to mimic container-managed authentication.=20 To test a "Save" is also pretty simple.=20 public void testSave() throws Exception {=20 setRequestPathInfo("/editPerson");=20 addRequestParameter("action", "Edit");=20 addRequestParameter("id", "1");=20 actionPerform();=20 assertTrue(getRequest().getAttribute(Constants.PERSON_KEY) !=3D = =20 null);=20 setRequestPathInfo("/savePerson");=20 addRequestParameter("action", "Save");=20 actionPerform();=20 verifyForward("edit");=20 verifyNoActionErrors();=20 }=20 I think you have something similar to this with the Mock Object you're =20 using in Spring. It just needs to be packaged up as a JAR. I'll be =20 more than happy to write up some documentation on how to use it.=20 Matt=20 On Apr 24, 2004, at 4:27 AM, j=FCrgen h=F6ller [werk3AT] wrote:=20 > Matt,=20 >=20 > I just tried using MockHttpServletRequest and MockHttpServletResponse = > from MockObjects with a Spring FormController. Unfortunately, those =20 > MockObjects mocks are really not well-suited for testing here, as it's = =20 > so much hassle to setup any kind of HttpServletRequest method access. = > What request/response mocks do you use for testing Struts Actions?=20 >=20 > Juergen=20 >=20 >=20 > ________________________________=20 >=20 > Von: spr...@li... im Auftrag von =20 > j=FCrgen h=F6ller [werk3AT]=20 > Gesendet: Sa 24.04.2004 10:57=20 > An: spr...@li...=20 > Betreff: Re: [Springframework-user] Testing Controllers and =20 > FormControllers=20 >=20 >=20 >=20 > I don't see much difference between testing Controllers and =20 > FormControllers: Both share the same "ModelAndView =20 > handleRequest(HttpServletRequest, HttpServletResponse)" method that =20 > you need to invoke for testing. As of 1.0.1, you shouldn't need a =20 > ServletContext mock anymore (except when actually accessing the =20 > ServletContext), so all you need are HttpServletRequest and =20 > HttpServletResponse mocks. The mocks provided by the MockObjects =20 > project should be fine for this.=20 >=20 > Juergen=20 >=20 >=20 > ________________________________=20 >=20 > Von: spr...@li... im Auftrag von =20 > Matt Raible=20 > Gesendet: Fr 23.04.2004 20:48=20 > An: spr...@li...=20 > Betreff: [Springframework-user] Testing Controllers and = FormControllers=20 >=20 >=20 >=20 > I've found it pretty simple to test Controllers, but FormControllers =20 > are=20 > a different story. From looking at the FormControllerTestSuite (URL=20 > below), as well as many other Spring tests, it seems that a lot of=20 > internal mocks are used to test this stuff.=20 >=20 > So my question is - what do you recommend for the average Spring MVC=20 > person? What is the strategy we should be using to test our=20 > 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?=20 >=20 > Thanks,=20 >=20 > Matt=20 >=20 > http://monkeymachine.co.uk/spring/xref-test/org/springframework/web/=20 > serv=20 > let/mvc/FormControllerTestSuite.html=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------=20 > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek=20 > 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!=20 > http://www.thinkgeek.com/freeshipping/?cpg=3D12297=20 > _______________________________________________=20 > Springframework-user mailing list=20 > Spr...@li...=20 > https://lists.sourceforge.net/lists/listinfo/springframework-user=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------=20 > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek=20 > 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!=20 > http://www.thinkgeek.com/freeshipping/?cpg=12297=20 > _______________________________________________=20 > Springframework-user mailing list=20 > Spr...@li...=20 > https://lists.sourceforge.net/lists/listinfo/springframework-user=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------=20 > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek=20 > 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!=20 > http://www.thinkgeek.com/freeshipping/?cpg=12297=20 > _______________________________________________=20 > Springframework-user mailing list=20 > Spr...@li...=20 > https://lists.sourceforge.net/lists/listinfo/springframework-user=20 -------------------------------------------------------=20 This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek=20 For a limited time only, get FREE Ground shipping on all orders of $35=20 or more. Hurry up and shop folks, this offer expires April 30th!=20 http://www.thinkgeek.com/freeshipping/?cpg=12297=20 _______________________________________________=20 Springframework-user mailing list=20 Spr...@li...=20 https://lists.sourceforge.net/lists/listinfo/springframework-user=20 |
|
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 |
|
From: Dmitriy K. <dko...@ru...> - 2004-04-28 12:46:28
|
Juergen, I would vote for org.springframework.mock.* package names. Regards, Dmitriy. jürgen höller [werk3AT] wrote: > 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=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-04-28 12:57:47
|
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: >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 ------------------------------------------------------- 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 |
|
From: Thomas R. <tho...@tr...> - 2004-04-28 13:28:04
|
+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 > > > > > |
|
From: Colin S. <col...@ex...> - 2004-04-28 13:56:30
|
+1 on org.springframework.mock j=FCrgen h=F6ller [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, b= ecause 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 any= way: They are mainly used in our framework test suite. And whoever uses t= hem 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 t= esting 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.springfra= mework.jndi.mock / org.springframework.web.mock or org.springframework.mo= ck.jndi / org.springframework.mock.web? I guess the latter is more approp= riate, 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, althoug= h >I'd really prefer a dedicated tree there as well. I'm sure that other st= uff >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] Test= ing >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 m= ocks >are so inconvenient to use. The current Spring-provided Servlet API mock= s >are by no means in a polished state, though: They're just good enough fo= r >being used within the framework test suite. They'd need some serious >refinement for making them public - after all, we have a reputation to l= ose >:-) > =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 lik= e to >include them in the main Spring sources, in a org.springframework.web.mo= ck >package: They would naturally be part of spring.jar and spring-web.jar t= hen. >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 Spri= ng >> =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 nee= ds >an HttpServletRequest and an HttpServletResponse). Including them in the >standard distribution would also indicate our strong focus on testabilit= y. > =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, th= e >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 co= uple >of classes, thus hardly worth a separate source tree. > =20 > >>IMO, the main concern regarding additions to the main Spring codebase i= s >> =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 St= ruts >support classes and those Servlet API mocks will at best see slight >refinements but certainly not exponential growth. So the former seems li= ke 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 necess= ary >> =20 >> >for testing most parts of a typical Spring app, respectively just interf= aces >that can conveniently be mocked in a dynamic fashion with EasyMock. Ther= e >are just two exceptions, as far I see: Our SimpleNamingContext stuff eas= es >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 fur= ther >> =20 >> >consideration. JDBC can quite nicely be mocked with EasyMock; it's >preferable to use the JdbcOperations interface as far as possible, thoug= h. >Same for a Hibernate Session, with HibernateOperations being preferable. >It's more or less just the Servlet API that's really tedious to mock wit= h >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 FormController= s >>> >>> >>> >>>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 >>> |
|
From: Alef A. <al...@jt...> - 2004-04-28 17:12:04
|
+1 on the org.springframework.mock.* packages,=20 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 > -----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 >=20 > 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. >=20 > 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. >=20 > Juergen >=20 >=20 > -----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 >=20 >=20 > 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. >=20 > 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. >=20 > So this looks like: >=20 > * 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) >=20 > * a "spring-mock.jar", generated from the "mock" directory by the = build > script, shipped in the "dist" directory of our distribution >=20 > 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. >=20 > 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. >=20 > Juergen >=20 >=20 > -----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 >=20 >=20 > 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. >=20 > 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. >=20 > Rgds, > Rod >=20 > ----- 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 >=20 >=20 > 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. >=20 > j=FCrgen h=F6ller [werk3AT] wrote: >=20 > >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 > >> > >> >=20 >=20 >=20 > ------------------------------------------------------- > 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 >=20 >=20 >=20 >=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 >=20 >=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 >=20 >=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 |
|
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 >>>> |
|
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 |
|
From: Luke T. <ne...@fr...> - 2004-04-29 21:57:55
|
jürgen höller [werk3AT] wrote: > BTW, I've already committed the factored-out "mock" tree, including adapted build scripts etc. > > Juergen > It looks like the target/mock-classes directory needs to be created in build.xml to stop it falling over on a clean build. Not quite sure how I'm going to squeeze it into the Maven build yet... Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523C http://www.monkeymachine.ltd.uk |
|
From: Luke T. <lu...@mo...> - 2004-04-29 22:19:37
|
Luke Taylor wrote: > > It looks like the target/mock-classes directory needs to be created in > build.xml to stop it falling over on a clean build. > It was just that the mockjar target had "build" as a dependency rather than "buildmock". I've changed it in CVS. > Not quite sure how I'm going to squeeze it into the Maven build yet... > I'm not sure I see the benefit of a separate "mock" tree in the main directory rather than just storing them as support classes in the test tree (since they're required by the test classes anyway). It would be easy enough to build the separate jar of the org.springframework.mock package from the compiled test classes. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523C http://www.monkeymachine.ltd.uk |
|
From: Colin S. <col...@ex...> - 2004-04-30 01:15:14
|
Luke Taylor wrote: > Luke Taylor wrote: > >> >> It looks like the target/mock-classes directory needs to be created >> in build.xml to stop it falling over on a clean build. >> > > It was just that the mockjar target had "build" as a dependency rather > than "buildmock". I've changed it in CVS. > >> Not quite sure how I'm going to squeeze it into the Maven build yet... >> > > I'm not sure I see the benefit of a separate "mock" tree in the main > directory rather than just storing them as support classes in the test > tree (since they're required by the test classes anyway). It would be > easy enough to build the separate jar of the org.springframework.mock > package from the compiled test classes. Actually that's a pretty valid point... |
|
From: <jue...@we...> - 2004-04-30 06:01:47
|
IMO, there's a strong difference between the "mock" and the "test" tree: = The latter is a rough test suite for the framework itself, while the = former contains polished mock classes that are also useful for = applications, thus get distributed as "spring-mock.jar". The mocks would = even fit better in "src" than in "test" in that respect. =20 Actually, the "mock" tree is more similar to the main "src" tree than = the "test" tree in a number of respects: It's meant to be used by = applications, shipped as jar , included in the javadoc, and requires = higher coding standards than the framework test suite. I'm quite = strongly against keeping that sort of classes in the "test" tree. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Fr 30.04.2004 03:18 An: spr...@li... Betreff: Re: [Springframework-developer] Testing Controllers and = FormControllers Luke Taylor wrote: > Luke Taylor wrote: > >> >> It looks like the target/mock-classes directory needs to be created >> in build.xml to stop it falling over on a clean build. >> > > It was just that the mockjar target had "build" as a dependency rather > than "buildmock". I've changed it in CVS. > >> Not quite sure how I'm going to squeeze it into the Maven build = yet... >> > > I'm not sure I see the benefit of a separate "mock" tree in the main > directory rather than just storing them as support classes in the test > tree (since they're required by the test classes anyway). It would be > easy enough to build the separate jar of the org.springframework.mock > package from the compiled test classes. Actually that's a pretty valid point... ------------------------------------------------------- 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_id=3D3149&alloc_id=3D8166&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Luke T. <ne...@fr...> - 2004-04-30 19:44:09
|
My main concern isn't so much whether they are in the test or src tree, it's just that the overall structure seems a bit haphazard. And I don't see why they should be split from the core when other modules aren't. If separate modules are going to be split from the codebase then it would make sense to follow a standard pattern, e.g. core | - src | - test mock | - src other | - src | - test Ok, Ok... so my main concern is that it won't work with my Maven build unless I hack it :) and until then my reports are stuck at Apr 28th. But I agree with the aims Maven had of establishing a common structure for project layouts, even though you could easily argue that they aren't exactly a shining example of best practice development themselves. Luke. jürgen höller [werk3AT] wrote: > IMO, there's a strong difference between the "mock" and the "test" > tree: The latter is a rough test suite for the framework itself, > while the former contains polished mock classes that are also useful > for applications, thus get distributed as "spring-mock.jar". The > mocks would even fit better in "src" than in "test" in that respect. > > Actually, the "mock" tree is more similar to the main "src" tree than > the "test" tree in a number of respects: It's meant to be used by > applications, shipped as jar , included in the javadoc, and requires > higher coding standards than the framework test suite. I'm quite > strongly against keeping that sort of classes in the "test" tree. > > Juergen > > -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523C http://www.monkeymachine.ltd.uk |
|
From: <jue...@we...> - 2004-05-02 11:27:42
|
While I object to keeping our new mocks in the "test" tree, I'm not = against keeping them in the "src" tree, excluding them from spring.jar = and Clover coverage. Rod was quite keen on having the separate "mock" = tree, so I guess we need to wait for his opinion, taking into account = the Maven issue. Unfortunately, he won't be online before Tuesday = morning... =20 In any case, it's important to agree on this before 1.0.2, which is = currently scheduled for release in two weeks. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Luke Taylor Gesendet: Fr 30.04.2004 21:44 An: spr...@li... Betreff: Re: [Springframework-developer] Testing Controllers and = FormControllers My main concern isn't so much whether they are in the test or src tree, it's just that the overall structure seems a bit haphazard. And I don't see why they should be split from the core when other modules aren't. If separate modules are going to be split from the codebase then it would make sense to follow a standard pattern, e.g. core | - src | - test mock | - src other | - src | - test Ok, Ok... so my main concern is that it won't work with my Maven build unless I hack it :) and until then my reports are stuck at Apr 28th. But I agree with the aims Maven had of establishing a common structure for project layouts, even though you could easily argue that they aren't exactly a shining example of best practice development themselves. Luke. j=FCrgen h=F6ller [werk3AT] wrote: > IMO, there's a strong difference between the "mock" and the "test" > tree: The latter is a rough test suite for the framework itself, > while the former contains polished mock classes that are also useful > for applications, thus get distributed as "spring-mock.jar". The > mocks would even fit better in "src" than in "test" in that respect. > > Actually, the "mock" tree is more similar to the main "src" tree than > the "test" tree in a number of respects: It's meant to be used by > applications, shipped as jar , included in the javadoc, and requires > higher coding standards than the framework test suite. I'm quite > strongly against keeping that sort of classes in the "test" tree. > > Juergen > > -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523C http://www.monkeymachine.ltd.uk ------------------------------------------------------- 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_id=3D3149&alloc_id=3D8166&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Luke T. <ne...@fr...> - 2004-05-02 22:13:42
|
jürgen höller [werk3AT] wrote: > While I object to keeping our new mocks in the "test" tree, I'm not > against keeping them in the "src" tree, excluding them from > spring.jar and Clover coverage. Rod was quite keen on having the > separate "mock" tree, so I guess we need to wait for his opinion, > taking into account the Maven issue. Unfortunately, he won't be > online before Tuesday morning... > I managed to get it to work OK with only a minor hack, so the reports and doc generation are running OK again. > In any case, it's important to agree on this before 1.0.2, which is > currently scheduled for release in two weeks. > Just one other minor request... Could you bump the version number in the Maven project.xml file whenever you tag a release? It'll keep the version listed on the site in line with the current codebase. Come to think of it, I should change it from 1.0 which is what it's reporting at the moment... Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523C http://www.monkeymachine.ltd.uk |
|
From: Rod J. <rod...@in...> - 2004-05-02 13:17:43
|
I'd still prefer a separate tree. More for clarity when users =
browse code. A lot of people are likely to look at the source =
in the /src tree and be confused as to why there's test-
related stuff =
there that isn't in spring.jar.
Rgds,
Rod
---- Original message -=
---
>Date: Sun, 2 May 2004 13:26:29 +0200
>From: j=FCrgen h=F6ller [we=
rk3AT] <jue...@we...> =
>Subject: Re: [Springframework-developer] Testing Controllers =
and FormControllers =
>To: <spr...@li...>
>
>While I obje=
ct to keeping our new mocks in the "test" tree, =
I'm not against keeping them in the "src" tree, excluding =
them from spring.jar and Clover coverage. Rod was quite keen =
on having the separate "mock" tree, so I guess we need to =
wait for his opinion, taking into account the Maven issue. =
Unfortunately, he won't be online before Tuesday morning...
> =
>In any case, it's important to agree on this before 1.0.2, =
which is currently scheduled for release in two weeks.
> =
>Juergen
> =
>
>________________________________
>
>Von: springframework-developer=
-ad...@li... =
im Auftrag von Luke Taylor
>Gesendet: Fr 30.04.2004 21:44
>An: springf=
ram...@li...
>Betreff: Re: [Springframework=
-developer] Testing Controllers =
and FormControllers
>
>
>
>My main concern isn't so much whether the=
y are in the test =
or src tree,
>it's just that the overall structure seems a bit haphazar=
d. =
And I don't
>see why they should be split from the core when other =
modules aren't.
>
>If separate modules are going to be split from the =
codebase =
then it
>would make sense to follow a standard pattern, e.g.
>
>core
> |
> - src
> |
> - test
>
>mock
> |
> - src
>
>other
> |
> - src
> |
> - test
>
>Ok, Ok... so my main concern is t=
hat it won't work with my =
Maven build
>unless I hack it :) and until then my reports are stuck at=
=
Apr 28th. But
>I agree with the aims Maven had of establishing a common=
=
structure for
>project layouts, even though you could easily argue that=
=
they aren't
>exactly a shining example of best practice development =
themselves.
>
>Luke.
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>> IMO, =
there's a strong difference between the "mock" and =
the "test"
>> tree: The latter is a rough test suite for the framework =
=
itself,
>> while the former contains polished mock classes that are =
also useful
>> for applications, thus get distributed as "spring-
mock=
.jar". The
>> mocks would even fit better in "src" than in "test" in =
that respect.
>>
>> Actually, the "mock" tree is more similar to the
main "src" tree than
>> the "test" tree in a number of respects: It's m=
eant to be =
used by
>> applications, shipped as jar , included in the javadoc, =
and requires
>> higher coding standards than the framework test suite. =
I'm =
quite
>> strongly against keeping that sort of classes in =
the "test" tree.
>>
>> Juergen
>>
>>
>
>
>
>--
> Luke Taylor. =
Monkey Machine Ltd.
> PGP Key ID: 0x57E9523C =
=
http://www.monkeymachine.ltd.uk
>
>
>
>
>--------------------------=
-----------------------------
>This SF.Net email is sponsored by: Oracl=
e 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_id=3D3149&alloc_id=3D8166&op=3Dclick
>_=
______________________________________________
>Springframework-develop=
er mailing list
>Spr...@li...
>http=
s://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=8166&op=C0ick
>________________=
_______________________________
>Springframework-developer mailing list=
>Spr...@li...
>https://lists.sourc=
eforge.net/lists/listinfo/springframework-
developer
|
|
From: Alef A. <al...@jt...> - 2004-05-02 14:15:18
|
> I'd still prefer a separate tree. More for clarity when users > browse code. A lot of people are likely to look at the source > in the /src tree and be confused as to why there's test- > related stuff there that isn't in spring.jar. +1 It will result in all kinds of questions popping up on the lists. What about a separate module? Or did I miss the discussion there. It = would allow for separate development of the mock tree (and maybe other test-related stuff). I imagine the amount of test-related supporting features for 1.0.x to grow before 1.1 is released and people will be = able to use those enhancements as they are contained by separate releases (as opposed to having them in the src or mock tree alongside the 1.0.x = codebase which might not be getting another release anymore). A separate module does however result in more complexity and work when = doing releases and stuff maybe... Alef >=20 > Rgds, > Rod >=20 > ---- Original message ---- > >Date: Sun, 2 May 2004 13:26:29 +0200 > >From: j=FCrgen h=F6ller [werk3AT] <jue...@we...> > >Subject: Re: [Springframework-developer] Testing Controllers > and FormControllers > >To: <spr...@li...> > > > >While I object to keeping our new mocks in the "test" tree, > I'm not against keeping them in the "src" tree, excluding > them from spring.jar and Clover coverage. Rod was quite keen > on having the separate "mock" tree, so I guess we need to > wait for his opinion, taking into account the Maven issue. > Unfortunately, he won't be online before Tuesday morning... > > > >In any case, it's important to agree on this before 1.0.2, > which is currently scheduled for release in two weeks. > > > >Juergen > > > > > >________________________________ > > > >Von: spr...@li... > im Auftrag von Luke Taylor > >Gesendet: Fr 30.04.2004 21:44 > >An: spr...@li... > >Betreff: Re: [Springframework-developer] Testing Controllers > and FormControllers > > > > > > > >My main concern isn't so much whether they are in the test > or src tree, > >it's just that the overall structure seems a bit haphazard. > And I don't > >see why they should be split from the core when other > modules aren't. > > > >If separate modules are going to be split from the codebase > then it > >would make sense to follow a standard pattern, e.g. > > > >core > > | > > - src > > | > > - test > > > >mock > > | > > - src > > > >other > > | > > - src > > | > > - test > > > >Ok, Ok... so my main concern is that it won't work with my > Maven build > >unless I hack it :) and until then my reports are stuck at > Apr 28th. But > >I agree with the aims Maven had of establishing a common > structure for > >project layouts, even though you could easily argue that > they aren't > >exactly a shining example of best practice development > themselves. > > > >Luke. > > > >j=FCrgen h=F6ller [werk3AT] wrote: > >> IMO, there's a strong difference between the "mock" and > the "test" > >> tree: The latter is a rough test suite for the framework > itself, > >> while the former contains polished mock classes that are > also useful > >> for applications, thus get distributed as "spring- > mock.jar". The > >> mocks would even fit better in "src" than in "test" in > that respect. > >> > >> Actually, the "mock" tree is more similar to the > main "src" tree than > >> the "test" tree in a number of respects: It's meant to be > used by > >> applications, shipped as jar , included in the javadoc, > and requires > >> higher coding standards than the framework test suite. I'm > quite > >> strongly against keeping that sort of classes in > the "test" tree. > >> > >> Juergen > >> > >> > > > > > > > >-- > > Luke Taylor. Monkey Machine Ltd. > > PGP Key ID: 0x57E9523C > http://www.monkeymachine.ltd.uk > > > > > > > > > >------------------------------------------------------- > >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=3Dclick > >_______________________________________________ > >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=8166&op=C0ick > >_______________________________________________ > >Springframework-developer mailing list > >Spr...@li... > >https://lists.sourceforge.net/lists/listinfo/springframework- > developer >=20 >=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 |
|
From: <jue...@we...> - 2004-05-02 15:00:20
|
I don't think that a separate mock module makes much sense: After all, = the "test" tree of the framework itself depends on those mocks... It = really should stay part of the main module. As you say, it's also easier = in terms of release management. =20 I don't think that the mocks will grow into something with its own = release schedule: We're still recommending dynamic mocks a la EasyMock = for most testing scenarios. Just when interfaces are really hard to mock = dynamically because of inter-dependent and overlapping methods = (attribute handling, parameters), we provide distinct mock objects: = currently, just for the Servlet API and for JNDI. The only further = candidate that I can think of at this point of time is the Portlet API. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Alef Arendsen Gesendet: So 02.05.2004 16:18 An: spr...@li... Betreff: RE: [Springframework-developer] Testing Controllers and = FormControllers > I'd still prefer a separate tree. More for clarity when users > browse code. A lot of people are likely to look at the source > in the /src tree and be confused as to why there's test- > related stuff there that isn't in spring.jar. +1 It will result in all kinds of questions popping up on the lists. What about a separate module? Or did I miss the discussion there. It = would allow for separate development of the mock tree (and maybe other test-related stuff). I imagine the amount of test-related supporting features for 1.0.x to grow before 1.1 is released and people will be = able to use those enhancements as they are contained by separate releases (as opposed to having them in the src or mock tree alongside the 1.0.x = codebase which might not be getting another release anymore). A separate module does however result in more complexity and work when = doing releases and stuff maybe... Alef > > Rgds, > Rod > > ---- Original message ---- > >Date: Sun, 2 May 2004 13:26:29 +0200 > >From: j=FCrgen h=F6ller [werk3AT] <jue...@we...> > >Subject: Re: [Springframework-developer] Testing Controllers > and FormControllers > >To: <spr...@li...> > > > >While I object to keeping our new mocks in the "test" tree, > I'm not against keeping them in the "src" tree, excluding > them from spring.jar and Clover coverage. Rod was quite keen > on having the separate "mock" tree, so I guess we need to > wait for his opinion, taking into account the Maven issue. > Unfortunately, he won't be online before Tuesday morning... > > > >In any case, it's important to agree on this before 1.0.2, > which is currently scheduled for release in two weeks. > > > >Juergen > > > > > >________________________________ > > > >Von: spr...@li... > im Auftrag von Luke Taylor > >Gesendet: Fr 30.04.2004 21:44 > >An: spr...@li... > >Betreff: Re: [Springframework-developer] Testing Controllers > and FormControllers > > > > > > > >My main concern isn't so much whether they are in the test > or src tree, > >it's just that the overall structure seems a bit haphazard. > And I don't > >see why they should be split from the core when other > modules aren't. > > > >If separate modules are going to be split from the codebase > then it > >would make sense to follow a standard pattern, e.g. > > > >core > > | > > - src > > | > > - test > > > >mock > > | > > - src > > > >other > > | > > - src > > | > > - test > > > >Ok, Ok... so my main concern is that it won't work with my > Maven build > >unless I hack it :) and until then my reports are stuck at > Apr 28th. But > >I agree with the aims Maven had of establishing a common > structure for > >project layouts, even though you could easily argue that > they aren't > >exactly a shining example of best practice development > themselves. > > > >Luke. > > > >j=FCrgen h=F6ller [werk3AT] wrote: > >> IMO, there's a strong difference between the "mock" and > the "test" > >> tree: The latter is a rough test suite for the framework > itself, > >> while the former contains polished mock classes that are > also useful > >> for applications, thus get distributed as "spring- > mock.jar". The > >> mocks would even fit better in "src" than in "test" in > that respect. > >> > >> Actually, the "mock" tree is more similar to the > main "src" tree than > >> the "test" tree in a number of respects: It's meant to be > used by > >> applications, shipped as jar , included in the javadoc, > and requires > >> higher coding standards than the framework test suite. I'm > quite > >> strongly against keeping that sort of classes in > the "test" tree. > >> > >> Juergen > >> > >> > > > > > > > >-- > > Luke Taylor. Monkey Machine Ltd. > > PGP Key ID: 0x57E9523C > http://www.monkeymachine.ltd.uk > > > > > > > > > >------------------------------------------------------- > >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=3Dclick > >_______________________________________________ > >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=8166&op=C0ick > >_______________________________________________ > >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=8166&op=3Dick > _______________________________________________ > 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=8166&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Thomas R. <tho...@tr...> - 2004-05-02 16:07:04
|
There is a SpringMockDataSource in the org.springframework.jdbc.support.SQLErrorCodesFactoryTests class. Don't think it is of any value for general use right now, but it was needed for the translation factory tests since every single instance of the easy mock datasource always returned the same hash value. Thomas jürgen höller [werk3AT] wrote: >I don't think that a separate mock module makes much sense: After all, the "test" tree of the framework itself depends on those mocks... It really should stay part of the main module. As you say, it's also easier in terms of release management. > >I don't think that the mocks will grow into something with its own release schedule: We're still recommending dynamic mocks a la EasyMock for most testing scenarios. Just when interfaces are really hard to mock dynamically because of inter-dependent and overlapping methods (attribute handling, parameters), we provide distinct mock objects: currently, just for the Servlet API and for JNDI. The only further candidate that I can think of at this point of time is the Portlet API. > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von Alef Arendsen >Gesendet: So 02.05.2004 16:18 >An: spr...@li... >Betreff: RE: [Springframework-developer] Testing Controllers and FormControllers > > > > > >>I'd still prefer a separate tree. More for clarity when users >>browse code. A lot of people are likely to look at the source >>in the /src tree and be confused as to why there's test- >>related stuff there that isn't in spring.jar. >> >> >+1 > >It will result in all kinds of questions popping up on the lists. > >What about a separate module? Or did I miss the discussion there. It would >allow for separate development of the mock tree (and maybe other >test-related stuff). I imagine the amount of test-related supporting >features for 1.0.x to grow before 1.1 is released and people will be able to >use those enhancements as they are contained by separate releases (as >opposed to having them in the src or mock tree alongside the 1.0.x codebase >which might not be getting another release anymore). > >A separate module does however result in more complexity and work when doing >releases and stuff maybe... > >Alef > > >>Rgds, >>Rod >> >>---- Original message ---- >> >> >>>Date: Sun, 2 May 2004 13:26:29 +0200 >>>From: jürgen höller [werk3AT] <jue...@we...> >>>Subject: Re: [Springframework-developer] Testing Controllers >>> >>> >>and FormControllers >> >> >>>To: <spr...@li...> >>> >>>While I object to keeping our new mocks in the "test" tree, >>> >>> >>I'm not against keeping them in the "src" tree, excluding >>them from spring.jar and Clover coverage. Rod was quite keen >>on having the separate "mock" tree, so I guess we need to >>wait for his opinion, taking into account the Maven issue. >>Unfortunately, he won't be online before Tuesday morning... >> >> >>>In any case, it's important to agree on this before 1.0.2, >>> >>> >>which is currently scheduled for release in two weeks. >> >> >>>Juergen >>> >>> >>>________________________________ >>> >>>Von: spr...@li... >>> >>> >>im Auftrag von Luke Taylor >> >> >>>Gesendet: Fr 30.04.2004 21:44 >>>An: spr...@li... >>>Betreff: Re: [Springframework-developer] Testing Controllers >>> >>> >>and FormControllers >> >> >>> >>>My main concern isn't so much whether they are in the test >>> >>> >>or src tree, >> >> >>>it's just that the overall structure seems a bit haphazard. >>> >>> >>And I don't >> >> >>>see why they should be split from the core when other >>> >>> >>modules aren't. >> >> >>>If separate modules are going to be split from the codebase >>> >>> >>then it >> >> >>>would make sense to follow a standard pattern, e.g. >>> >>>core >>> | >>> - src >>> | >>> - test >>> >>>mock >>> | >>> - src >>> >>>other >>> | >>> - src >>> | >>> - test >>> >>>Ok, Ok... so my main concern is that it won't work with my >>> >>> >>Maven build >> >> >>>unless I hack it :) and until then my reports are stuck at >>> >>> >>Apr 28th. But >> >> >>>I agree with the aims Maven had of establishing a common >>> >>> >>structure for >> >> >>>project layouts, even though you could easily argue that >>> >>> >>they aren't >> >> >>>exactly a shining example of best practice development >>> >>> >>themselves. >> >> >>>Luke. >>> >>>jürgen höller [werk3AT] wrote: >>> >>> >>>>IMO, there's a strong difference between the "mock" and >>>> >>>> >>the "test" >> >> >>>>tree: The latter is a rough test suite for the framework >>>> >>>> >>itself, >> >> >>>>while the former contains polished mock classes that are >>>> >>>> >>also useful >> >> >>>>for applications, thus get distributed as "spring- >>>> >>>> >>mock.jar". The >> >> >>>>mocks would even fit better in "src" than in "test" in >>>> >>>> >>that respect. >> >> >>>>Actually, the "mock" tree is more similar to the >>>> >>>> >>main "src" tree than >> >> >>>>the "test" tree in a number of respects: It's meant to be >>>> >>>> >>used by >> >> >>>>applications, shipped as jar , included in the javadoc, >>>> >>>> >>and requires >> >> >>>>higher coding standards than the framework test suite. I'm >>>> >>>> >>quite >> >> >>>>strongly against keeping that sort of classes in >>>> >>>> >>the "test" tree. >> >> >>>>Juergen >>>> >>>> >>>> >>>> >>> >>>-- >>> Luke Taylor. Monkey Machine Ltd. >>> PGP Key ID: 0x57E9523C >>> >>> >>http://www.monkeymachine.ltd.uk >> >> >>> >>> >>>------------------------------------------------------- >>>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 >> >> >>> >>> >>>------------------------------------------------------- >>>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=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 > > > > > |
|
From: Matt R. <li...@ra...> - 2004-04-27 19:55:39
|
+1 for including the polished Servlet API mocks in the main Spring
codebase. Here's an example of a UserFormControllerTest to test a
SimpleFormController using these mocks. They're not used much in this
example, but they sure make things a lot easier. The alternative is to
use Cactus to test these, but I've grown to loathe waiting for my
container to startup and run this stuff.
Matt
public class UserFormControllerTest extends TestCase {
private static Log log =3D
LogFactory.getLog(UserFormControllerTest.class);
private ApplicationContext ctx;
private UserFormController c;
public void setUp() throws Exception {
String[] paths =3D { "/applicationContext.xml",
"/action-servlet.xml" };
ctx =3D new ClassPathXmlApplicationContext(paths); =20
c =3D (UserFormController) ctx.getBean("userFormController");
}
=20
public void testDisplayEmptyForm() throws Exception {
MockHttpServletRequest request =3D
new MockHttpServletRequest(null, "GET", "/editUser.do");
HttpServletResponse response =3D new MockHttpServletResponse();
ModelAndView mv =3D c.handleRequest(request, response);
assertTrue("returned correct view name",
mv.getViewName().equals("userForm"));
}
public void testAddUser() throws Exception {
MockHttpServletRequest request =3D
new MockHttpServletRequest(null, "POST", "/editUser.do");
request.addParameter("firstName", "Matt");
request.addParameter("lastName", "Raible");
HttpServletResponse response =3D new MockHttpServletResponse();
ModelAndView mv =3D c.handleRequest(request, response);
Errors errors =3D
(Errors) mv.getModel().get(BindException.ERROR_KEY_PREFIX +
"user");
assertTrue("no errors returned in model", errors =3D=3D null);
assertNotNull(request.getSession().getAttribute("message"));
}
public void testSaveUserMissingLastName() throws Exception {
MockHttpServletRequest request =3D
new MockHttpServletRequest(null, "POST", "/editUser.do");
request.addParameter("firstName", "Julie");
HttpServletResponse response =3D new MockHttpServletResponse();
ModelAndView mv =3D c.handleRequest(request, response);
Errors errors =3D
(Errors) mv.getModel().get(BindException.ERROR_KEY_PREFIX +
"user");
assertTrue("errors returned in model", errors !=3D null);
assertNull(request.getSession().getAttribute("message"));
} =20
}
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]
> On Behalf Of j=FCrgen h=F6ller [werk3AT]
> Sent: Tuesday, April 27, 2004 11:58 AM
> To: spr...@li...
> Cc: spr...@li...
> Subject: [Springframework-developer] Re:=20
> [Springframework-user] Testing Controllers and FormControllers
>=20
>=20
> Matt, everybody,
>=20
> Essentially, the Servlet API mocks in Spring's test directory
> are just there because the MockObjects=20
> (http://www.mockobjects.com) Servlet API mocks are so=20
> inconvenient to use. The current Spring-provided Servlet API=20
> mocks are by no means in a polished state, though: They're=20
> just good enough for being used within the framework test=20
> suite. They'd need some serious refinement for making them=20
> public - after all, we have a reputation to lose :-)
>=20
> So on that occasion, I've reworked those mocks today, making
> them significantly more complete than before, and ready for=20
> getting included in the Spring distribution. The question is:=20
> Where to include them? I'd like to include them in the main=20
> Spring sources, in a org.springframework.web.mock package:=20
> They would naturally be part of spring.jar and spring-web.jar=20
> then. The test directory (where they currently reside) is no=20
> appropriate place, as it is about testing the framework=20
> rather than providing infrastructure classes.=20
>=20
> While it isn't in general appropriate to include mocks in the
> main Spring codebase, I guess this is a different case: Those=20
> mocks are specifically provided to ease testing of Spring web=20
> contexts (like XmlWebApplicationContext or=20
> StaticWebApplicationContext that need a ServletContext) and=20
> controllers (the Controller.handleRequest method needs an=20
> HttpServletRequest and an HttpServletResponse). Including=20
> them in the standard distribution would also indicate our=20
> strong focus on testability.
>=20
> The new MockServletContext implementation uses the
> org.springframework.core.io.Resource API for resource=20
> loading, to allow for ServletContext.getResourceAsStream from=20
> any resource base. So partly, the mock implementations depend=20
> on low-level Spring API. We could of course keep the mocks in=20
> a separate part of the Spring CVS, but it's just about a=20
> couple of classes, thus hardly worth a separate source tree.
>=20
> IMO, the main concern regarding additions to the main Spring
> codebase is whether those additions can potentially grow=20
> significantly: While Keith's rules API in the sandbox has=20
> definite potential there (so had Ben Alex' security framework=20
> that became the Acegi Security System), the recent Struts=20
> support classes and those Servlet API mocks will at best see=20
> slight refinements but certainly not exponential growth. So=20
> the former seems like a candidate for a separate module to=20
> me, while the latter should fit into the main Spring codebase.
>=20
> An important point to consider is that there are simply no
> mocks necessary for testing most parts of a typical Spring=20
> app, respectively just interfaces that can conveniently be=20
> mocked in a dynamic fashion with EasyMock. There are just two=20
> exceptions, as far I see: Our SimpleNamingContext stuff eases=20
> custom JNDI environments, and the newly refined set of=20
> Servlet API mocks allows for convenient testing of Spring web=20
> MVC (and web contexts).
>=20
> Mocking an EJB container is next to impossible, so that's not
> worth further consideration. JDBC can quite nicely be mocked=20
> with EasyMock; it's preferable to use the JdbcOperations=20
> interface as far as possible, though. Same for a Hibernate=20
> Session, with HibernateOperations being preferable. It's more=20
> or less just the Servlet API that's really tedious to mock=20
> with EasyMock, due to all those interdependent methods (e.g.=20
> URL paths, parameters, attributes).
>=20
> What does everybody think? Does anyone mind including those
> polished Servlet API mocks in the main Spring codebase,=20
> already for 1.0.2? Any suggestions for alternatives?
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]On Behalf Of=20
> Matt Raible=20
> Sent: Saturday, April 24, 2004 2:02 PM=20
> To: spr...@li...=20
> Subject: Re: [Springframework-user] Testing Controllers and=20
> FormControllers=20
>=20
>=20
> I use StrutsTestCase (http://strutstestcase.sf.net), which
> allows you =20
> to write very little code to test an Action. Here is a=20
> simple example =20
> of testing an "execute" method:=20
>=20
> package org.appfuse.webapp.action;
>=20
> import servletunit.struts.CactusStrutsTestCase;
> import org.appfuse.Constants;=20
>=20
> public class PersonActionTest extends CactusStrutsTestCase {
> =20
> public PersonActionTest(String name) {=20
> super(name);=20
> }
>=20
> public void testExecute() {=20
> // test execute method=20
> setRequestPathInfo("/editPerson");=20
> addRequestParameter("id", "1");=20
> actionPerform();=20
> verifyNoActionErrors();
> =20
> assertNotNull(getRequest().getAttribute(Constants.PERSON_KEY));=20
> }
>=20
> public static void main(String[] args) {=20
> junit.textui.TestRunner.run(PersonActionTest.class);=20
> }
> }=20
>=20
> Since CactusStrutsTestCase extends from Cactus, I can also
> use Cactus's =20
> FormAuthentication support to mimic container-managed authentication.=20
>=20
> To test a "Save" is also pretty simple.
>=20
> public void testSave() throws Exception {=20
> setRequestPathInfo("/editPerson");=20
> addRequestParameter("action", "Edit");=20
> addRequestParameter("id", "1");
>=20
> actionPerform();
>=20
> =20
> assertTrue(getRequest().getAttribute(Constants.PERSON_KEY) !=3D
> null);=20
>=20
> setRequestPathInfo("/savePerson");=20
> addRequestParameter("action", "Save");=20
> actionPerform();=20
> verifyForward("edit");=20
> verifyNoActionErrors();=20
> }
>=20
> I think you have something similar to this with the Mock
> Object you're =20
> using in Spring. It just needs to be packaged up as a JAR. I'll be =20
> more than happy to write up some documentation on how to use it.=20
>=20
> Matt
>=20
>=20
> On Apr 24, 2004, at 4:27 AM, j=FCrgen h=F6ller [werk3AT] wrote:
>=20
> > Matt,
> >=20
> > 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?
> >=20
> > Juergen
> >=20
> >=20
> > ________________________________
> >=20
> > Von: spr...@li... im Auftrag von
> > j=FCrgen h=F6ller [werk3AT]
> > Gesendet: Sa 24.04.2004 10:57
> > An: spr...@li...=20
> > Betreff: Re: [Springframework-user] Testing Controllers and =20
> > FormControllers=20
> >=20
> >=20
> >=20
> > I don't see much difference between testing Controllers and
> > FormControllers: Both share the same "ModelAndView
> > handleRequest(HttpServletRequest, HttpServletResponse)"=20
> 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 =20
> > ServletContext), so all you need are HttpServletRequest and =20
> > HttpServletResponse mocks. The mocks provided by the MockObjects =20
> > project should be fine for this.=20
> >=20
> > Juergen
> >=20
> >=20
> > ________________________________
> >=20
> > Von: spr...@li... im Auftrag von
> > Matt Raible
> > Gesendet: Fr 23.04.2004 20:48
> > An: spr...@li...=20
> > Betreff: [Springframework-user] Testing Controllers and=20
> FormControllers
> >=20
> >=20
> >=20
> > 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.=20
> >=20
> > 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=20
> > 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?
> >=20
> > Thanks,
> >=20
> > Matt
> >=20
> > http://monkeymachine.co.uk/spring/xref-test/org/springframework/web/
> > serv
> > let/mvc/FormControllerTestSuite.html=20
> >=20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> > For a limited time only, get FREE Ground shipping on all=20
> orders of $35
> > or more. Hurry up and shop folks, this offer expires April 30th!
> > http://www.thinkgeek.com/freeshipping/?cpg=3D12297=20
> > _______________________________________________=20
> > Springframework-user mailing list=20
> > Spr...@li...=20
> > https://lists.sourceforge.net/lists/listinfo/springframework-user=20
> >=20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> > For a limited time only, get FREE Ground shipping on all=20
> orders of $35
> > or more. Hurry up and shop folks, this offer expires April 30th!
> > http://www.thinkgeek.com/freeshipping/?cpg=12297=20
> > _______________________________________________=20
> > Springframework-user mailing list=20
> > Spr...@li...=20
> > https://lists.sourceforge.net/lists/listinfo/springframework-user=20
> >=20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> > For a limited time only, get FREE Ground shipping on all=20
> orders of $35
> > or more. Hurry up and shop folks, this offer expires April 30th!
> > http://www.thinkgeek.com/freeshipping/?cpg=12297=20
> > _______________________________________________=20
> > Springframework-user mailing list=20
> > Spr...@li...=20
> > https://lists.sourceforge.net/lists/listinfo/springframework-user=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek=20
> For a limited time only, get FREE Ground shipping on all=20
> orders of $35=20
> or more. Hurry up and shop folks, this offer expires April 30th!=20
> http://www.thinkgeek.com/freeshipping/?cpg=12297=20
> _______________________________________________=20
> Springframework-user mailing list=20
> Spr...@li...=20
> https://lists.sourceforge.net/lists/listinfo/springframework-user=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek=20
> 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!=20
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
|
|
From: Colin S. <col...@ex...> - 2004-04-27 20:30:25
|
I'm ok with including these in Spring; if people feel they are too big,=20 they could be a spring-test add-on jar, that's not even included in the=20 main spring.jar which normally included all the optional stuff. That=20 makes some sense since this is for testing. j=FCrgen h=F6ller [werk3AT] wrote: >Matt, everybody,=20 > >Essentially, the Servlet API mocks in Spring's test directory are just t= here because the MockObjects (http://www.mockobjects.com) Servlet API moc= ks are so inconvenient to use. The current Spring-provided Servlet API mo= cks 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 l= ose :-) > >So on that occasion, I've reworked those mocks today, making them signif= icantly 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.moc= k 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 infrast= ructure classes.=20 > >While it isn't in general appropriate to include mocks in the main Sprin= g codebase, I guess this is a different case: Those mocks are specificall= y provided to ease testing of Spring web contexts (like XmlWebApplication= Context or StaticWebApplicationContext that need a ServletContext) and co= ntrollers (the Controller.handleRequest method needs an HttpServletReques= t and an HttpServletResponse). Including them in the standard distributio= n would also indicate our strong focus on testability. > >The new MockServletContext implementation uses the org.springframework.c= ore.io.Resource API for resource loading, to allow for ServletContext.get= ResourceAsStream from any resource base. So partly, the mock implementati= ons 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 classe= s, 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 St= ruts support classes and those Servlet API mocks will at best see slight = refinements but certainly not exponential growth. So the former seems lik= e a candidate for a separate module to me, while the latter should fit in= to the main Spring codebase. > >An important point to consider is that there are simply no mocks necessa= ry for testing most parts of a typical Spring app, respectively just inte= rfaces that can conveniently be mocked in a dynamic fashion with EasyMock= . There are just two exceptions, as far I see: Our SimpleNamingContext st= uff eases custom JNDI environments, and the newly refined set of Servlet = API mocks allows for convenient testing of Spring web MVC (and web contex= ts). > >Mocking an EJB container is next to impossible, so that's not worth furt= her consideration. JDBC can quite nicely be mocked with EasyMock; it's pr= eferable 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, param= eters, attributes). > >What does everybody think? Does anyone mind including those polished Ser= vlet API mocks in the main Spring codebase, already for 1.0.2? Any sugges= tions for alternatives? > >Juergen > > >-----Original Message-----=20 >From: spr...@li...=20 >[mailto:spr...@li...]On Behalf Of=20 >Matt Raible=20 >Sent: Saturday, April 24, 2004 2:02 PM=20 >To: spr...@li...=20 >Subject: Re: [Springframework-user] Testing Controllers and=20 >FormControllers=20 > > >I use StrutsTestCase (http://strutstestcase.sf.net), which allows you =20 >to write very little code to test an Action. Here is a simple example =20 >of testing an "execute" method:=20 > >package org.appfuse.webapp.action;=20 > >import servletunit.struts.CactusStrutsTestCase;=20 >import org.appfuse.Constants;=20 > >public class PersonActionTest extends CactusStrutsTestCase {=20 > =20 > public PersonActionTest(String name) {=20 > super(name);=20 > }=20 > > public void testExecute() {=20 > // test execute method=20 > setRequestPathInfo("/editPerson");=20 > addRequestParameter("id", "1");=20 > actionPerform();=20 > verifyNoActionErrors();=20 > assertNotNull(getRequest().getAttribute(Constants.PERSON_KEY));= =20 > }=20 > > public static void main(String[] args) {=20 > junit.textui.TestRunner.run(PersonActionTest.class);=20 > }=20 >}=20 > >Since CactusStrutsTestCase extends from Cactus, I can also use Cactus's = =20 >FormAuthentication support to mimic container-managed authentication.=20 > >To test a "Save" is also pretty simple.=20 > > public void testSave() throws Exception {=20 > setRequestPathInfo("/editPerson");=20 > addRequestParameter("action", "Edit");=20 > addRequestParameter("id", "1");=20 > > actionPerform();=20 > > assertTrue(getRequest().getAttribute(Constants.PERSON_KEY) !=3D= =20 >null);=20 > > setRequestPathInfo("/savePerson");=20 > addRequestParameter("action", "Save");=20 > actionPerform();=20 > verifyForward("edit");=20 > verifyNoActionErrors();=20 > }=20 > >I think you have something similar to this with the Mock Object you're =20 >using in Spring. It just needs to be packaged up as a JAR. I'll be =20 >more than happy to write up some documentation on how to use it.=20 > >Matt=20 > > >On Apr 24, 2004, at 4:27 AM, j=FCrgen h=F6ller [werk3AT] wrote:=20 > > =20 > >>Matt,=20 >> >>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 = =20 >>so much hassle to setup any kind of HttpServletRequest method access. =20 >>What request/response mocks do you use for testing Struts Actions?=20 >> >>Juergen=20 >> >> >>________________________________=20 >> >>Von: spr...@li... im Auftrag von =20 >>j=FCrgen h=F6ller [werk3AT]=20 >>Gesendet: Sa 24.04.2004 10:57=20 >>An: spr...@li...=20 >>Betreff: Re: [Springframework-user] Testing Controllers and =20 >>FormControllers=20 >> >> >> >>I don't see much difference between testing Controllers and =20 >>FormControllers: Both share the same "ModelAndView =20 >>handleRequest(HttpServletRequest, HttpServletResponse)" method that =20 >>you need to invoke for testing. As of 1.0.1, you shouldn't need a =20 >>ServletContext mock anymore (except when actually accessing the =20 >>ServletContext), so all you need are HttpServletRequest and =20 >>HttpServletResponse mocks. The mocks provided by the MockObjects =20 >>project should be fine for this.=20 >> >>Juergen=20 >> >> >>________________________________=20 >> >>Von: spr...@li... im Auftrag von =20 >>Matt Raible=20 >>Gesendet: Fr 23.04.2004 20:48=20 >>An: spr...@li...=20 >>Betreff: [Springframework-user] Testing Controllers and FormControllers= =20 >> >> >> >>I've found it pretty simple to test Controllers, but FormControllers =20 >>are=20 >>a different story. From looking at the FormControllerTestSuite (URL=20 >>below), as well as many other Spring tests, it seems that a lot of=20 >>internal mocks are used to test this stuff.=20 >> >>So my question is - what do you recommend for the average Spring MVC=20 >>person? What is the strategy we should be using to test our=20 >>controllers? Should we be using the Mocks that Spring provides? This=20 >>would certainly make things easier. If we're supposed to do that - is=20 >>it possible to get these mocks distributed in a JAR?=20 >> >>Thanks,=20 >> >>Matt=20 >> >>http://monkeymachine.co.uk/spring/xref-test/org/springframework/web/=20 >>serv=20 >>let/mvc/FormControllerTestSuite.html=20 >> =20 >> |
|
From: Rod J. <rod...@in...> - 2004-04-27 21:13:33
|
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 stu= ff 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] Testi= ng 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 mo= cks 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 lo= se :-) > >So on that occasion, I've reworked those mocks today, making them significantly more complete than before, and ready for getting included i= n 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.moc= k package: They would naturally be part of spring.jar and spring-web.jar th= en. 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 Sprin= g 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 need= s 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 f= or ServletContext.getResourceAsStream from any resource base. So partly, the mock implementations depend on low-level Spring API. We could of course k= eep the mocks in a separate part of the Spring CVS, but it's just about a cou= ple 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 Str= uts support classes and those Servlet API mocks will at best see slight refinements but certainly not exponential growth. So the former seems lik= e a candidate for a separate module to me, while the latter should fit into t= he main Spring codebase. > >An important point to consider is that there are simply no mocks necessa= ry for testing most parts of a typical Spring app, respectively just interfa= ces that can conveniently be mocked in a dynamic fashion with EasyMock. There are just two exceptions, as far I see: Our SimpleNamingContext stuff ease= s 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 furt= her 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 |
|
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 > > |
