Re: unit testing Struts2 application (with Spring and Hibernate)
I have updated the JUnit plugin, to provide support for this kind of testing(also for spring testing), see the documentation here: http://cwiki.apache.org/confluence/display/WW/Testing+Actions See the 2 classes here: http://svn.apache.org/viewvc/struts/struts2/trunk/plugins/junit/src/main/java/org/apache/struts2/ feedback is welcome, before 2.1.8 is released, using this classes you can test your action output like: public void testExecuteAction() throws ServletException, UnsupportedEncodingException { String output = executeAction(/test/testAction.action); assertEquals(Hello, output); } for something like this to work you will have to use FreeMarker or velocity for the results, or the experimental JSP plugin: http://cwiki.apache.org/S2PLUGINS/embedded-jsp-plugin.html musachy On Tue, Jul 21, 2009 at 2:26 PM, Dimitrios Christodoulakisdimi@gmail.com wrote: In your code below, where you say // and then execute proxy again, are you missing some stepls where you need to supply some parameters to the action? Yes, that wasn't actual code, just the steps I was considering. -In any case it's good to know the limitations of the example. You are right, sometimes I need to test a broader unit of work, which can include a couple of actions, rather than just one. So, in that sense, I could be stepping into the functional testing area. I appreciate all the helpful information. I've already learned a lot, by the example code, and the discussions on this thread! On Tue, Jul 21, 2009 at 3:31 PM, Haroon Rafiqueharoon.rafi...@utoronto.ca wrote: On Today at 2:02pm, DC=Dimitrios Christodoulakis dimi@gmail.com wrote: DC [..snip..] DC DC The CONFIG_LOCATIONS is used to initialize the servletContext which in DC turn is used to initialize the applicationContext, right? So, I am not DC sure where is the correct place to add the web.xml file, or how to DC tell BaseStrutsTestCase to include OpenEntityManagerInViewFilter DC during the recreation of the framework. DC The CONFIG_LOCATIONS variable is used to initialize spring only. I don't use spring-orm, so I can't comment on how to tell BaseStrutsTestCase to include that particular filter (or any other filter for that matter). DC DC Is that a limitation of this test class, or I am trying to include my DC web.xml file the wrong way? DC Most probably a limitation. DC DC I am not sure if other folks using this example code dealt with DC something like this in the past and solved it. Haroon, I hope you DC don't mind my asking you again about this :) DC DC Also, a more general question: Can the proxy class be used to create DC and run two actions sequentially? Let's say I want to test an action DC in my secure namespace, meaning that some sort of login or DC registration action comes first. DC I think you're over-stepping the bounds of unit testing here. In any case, I have created multiple invocations of the same action in the same test method without any problems. E.g., createAction(SomeAction.class, /namespace, actionName); //... set some parameters assertEquals(SUCCESS, proxy.execute()); //create action again createAction(SomeAction.class, /namespace, actionName); //... set some *different* parameters so that we expect INPUT to be // returned assertEquals(INPUT, proxy.execute()); There's nothing to prevent you from recreating another Action all together. You just have to remember that every time you execute createAction, it creates a new mock request and mock response, so you have to populate things properly. DC DC So, could I do something like this in my test method?: DC In your code below, where you say // and then execute proxy again, are you missing some stepls where you need to supply some parameters to the action? DC DC @Test DC public void testExecute() throws Exception{ DC Login testLogin = createAction(Login.class, /, Login); DC //set my fields DC testLogin.setPassword(...); DC //execute proxy once DC proxy.execute(); DC //Then create my secure action DC UpdateProfile testUpdateProfile = DC createAction(UpdateProfile.class, /secure, UpdateProfile); DC //and then execute proxy again DC proxy.execute(); DC } DC DC [..snip..] DC DC Up until now I manually created mock objects to satisfy any DC dependencies of the class under test: Created a user object and put in DC on a Session map manually to simulate a successful login action. So DC the motive here was to use this example test code to actually create DC and execute a successful test of the predecessor action (so the login DC action itself could add the logged in user to the session) before the DC actual action that I am primarily testing (updateProfile). DC Smells like functional testing to me. DC DC Anyway, I sure hope I am not stretching this conversation too far by DC experimenting a bit further with this example. Any suggestions are DC appreciated. DC DC
Re: unit testing Struts2 application (with Spring and Hibernate)
Thanks for this news! I will give it a try. On Fri, Aug 7, 2009 at 1:56 PM, Musachy Barrosomusa...@gmail.com wrote: I have updated the JUnit plugin, to provide support for this kind of testing(also for spring testing), see the documentation here: http://cwiki.apache.org/confluence/display/WW/Testing+Actions See the 2 classes here: http://svn.apache.org/viewvc/struts/struts2/trunk/plugins/junit/src/main/java/org/apache/struts2/ feedback is welcome, before 2.1.8 is released, using this classes you can test your action output like: public void testExecuteAction() throws ServletException, UnsupportedEncodingException { String output = executeAction(/test/testAction.action); assertEquals(Hello, output); } for something like this to work you will have to use FreeMarker or velocity for the results, or the experimental JSP plugin: http://cwiki.apache.org/S2PLUGINS/embedded-jsp-plugin.html musachy On Tue, Jul 21, 2009 at 2:26 PM, Dimitrios Christodoulakisdimi@gmail.com wrote: In your code below, where you say // and then execute proxy again, are you missing some stepls where you need to supply some parameters to the action? Yes, that wasn't actual code, just the steps I was considering. -In any case it's good to know the limitations of the example. You are right, sometimes I need to test a broader unit of work, which can include a couple of actions, rather than just one. So, in that sense, I could be stepping into the functional testing area. I appreciate all the helpful information. I've already learned a lot, by the example code, and the discussions on this thread! On Tue, Jul 21, 2009 at 3:31 PM, Haroon Rafiqueharoon.rafi...@utoronto.ca wrote: On Today at 2:02pm, DC=Dimitrios Christodoulakis dimi@gmail.com wrote: DC [..snip..] DC DC The CONFIG_LOCATIONS is used to initialize the servletContext which in DC turn is used to initialize the applicationContext, right? So, I am not DC sure where is the correct place to add the web.xml file, or how to DC tell BaseStrutsTestCase to include OpenEntityManagerInViewFilter DC during the recreation of the framework. DC The CONFIG_LOCATIONS variable is used to initialize spring only. I don't use spring-orm, so I can't comment on how to tell BaseStrutsTestCase to include that particular filter (or any other filter for that matter). DC DC Is that a limitation of this test class, or I am trying to include my DC web.xml file the wrong way? DC Most probably a limitation. DC DC I am not sure if other folks using this example code dealt with DC something like this in the past and solved it. Haroon, I hope you DC don't mind my asking you again about this :) DC DC Also, a more general question: Can the proxy class be used to create DC and run two actions sequentially? Let's say I want to test an action DC in my secure namespace, meaning that some sort of login or DC registration action comes first. DC I think you're over-stepping the bounds of unit testing here. In any case, I have created multiple invocations of the same action in the same test method without any problems. E.g., createAction(SomeAction.class, /namespace, actionName); //... set some parameters assertEquals(SUCCESS, proxy.execute()); //create action again createAction(SomeAction.class, /namespace, actionName); //... set some *different* parameters so that we expect INPUT to be // returned assertEquals(INPUT, proxy.execute()); There's nothing to prevent you from recreating another Action all together. You just have to remember that every time you execute createAction, it creates a new mock request and mock response, so you have to populate things properly. DC DC So, could I do something like this in my test method?: DC In your code below, where you say // and then execute proxy again, are you missing some stepls where you need to supply some parameters to the action? DC DC @Test DC public void testExecute() throws Exception{ DC Login testLogin = createAction(Login.class, /, Login); DC //set my fields DC testLogin.setPassword(...); DC //execute proxy once DC proxy.execute(); DC //Then create my secure action DC UpdateProfile testUpdateProfile = DC createAction(UpdateProfile.class, /secure, UpdateProfile); DC //and then execute proxy again DC proxy.execute(); DC } DC DC [..snip..] DC DC Up until now I manually created mock objects to satisfy any DC dependencies of the class under test: Created a user object and put in DC on a Session map manually to simulate a successful login action. So DC the motive here was to use this example test code to actually create DC and execute a successful test of the predecessor action (so the login DC action itself could add the logged in user to the session) before the DC actual action that I am primarily testing (updateProfile). DC Smells like functional testing to me. DC DC Anyway, I sure hope I am not
Re: unit testing Struts2 application (with Spring and Hibernate)
I have used this testing code to a certain extend, and seems to work fine. So I am interested in making it work against a complete test case scenario. So, when trying to load a child entity after the parent is retrieved, I get a LazyInitializationException Error. Sure enough, when the system tries to load the dependent collection, it doesn't find a session or thinks the session was closed. During development this is solved by the org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter filter declared in the web.xml file. So, I tried adding that file in the BaseStrutsTestCase in the CONFIG_LOCATIONS String: private static final String CONFIG_LOCATIONS = /WEB-INF/applicationContext.xml, + .../WEB-INF/web.xml; This time the error is: ERROR ContextLoader:215 - Context initialization failed org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://java.sun.com/xml/ns/j2ee] Offending resource: URL [file:/C:/./WebContent/WEB-INF/web.xml] The CONFIG_LOCATIONS is used to initialize the servletContext which in turn is used to initialize the applicationContext, right? So, I am not sure where is the correct place to add the web.xml file, or how to tell BaseStrutsTestCase to include OpenEntityManagerInViewFilter during the recreation of the framework. Is that a limitation of this test class, or I am trying to include my web.xml file the wrong way? I am not sure if other folks using this example code dealt with something like this in the past and solved it. Haroon, I hope you don't mind my asking you again about this :) Also, a more general question: Can the proxy class be used to create and run two actions sequentially? Let's say I want to test an action in my secure namespace, meaning that some sort of login or registration action comes first. So, could I do something like this in my test method?: @Test public void testExecute() throws Exception{ Login testLogin = createAction(Login.class, /, Login); //set my fields testLogin.setPassword(...); //execute proxy once proxy.execute(); //Then create my secure action UpdateProfile testUpdateProfile = createAction(UpdateProfile.class, /secure, UpdateProfile); //and then execute proxy again proxy.execute(); } This doesn't seem to work when I tried it. Could that be a violation of the ActionProxy rules? Before digging any deeper I just thought to ask this, in case there is another way to link and execute several sequential actions within the same test? Up until now I manually created mock objects to satisfy any dependencies of the class under test: Created a user object and put in on a Session map manually to simulate a successful login action. So the motive here was to use this example test code to actually create and execute a successful test of the predecessor action (so the login action itself could add the logged in user to the session) before the actual action that I am primarily testing (updateProfile). Anyway, I sure hope I am not stretching this conversation too far by experimenting a bit further with this example. Any suggestions are appreciated. Regards. On Mon, Jul 20, 2009 at 5:02 PM, Haroon Rafiqueharoon.rafi...@utoronto.ca wrote: On Today at 4:32pm, DC=Dimitrios Christodoulakis dimi@gmail.com wrote: DC Thanks Haroon for the handy advice. That seems to do the trick as far DC as the session object is concerned. The test passes now. DC Glad it worked out. DC DC Would it be easy for someone to extend your code to include actions DC that implement the -aware interfaces? If I wanted to take a shot at DC that, is there a particular point you would suggest I start with? DC Did you add that code in your Test class? I was actually suggesting that you modify the code inside BaseStrutsTestCase. So, I would recommend adding a private static HashMap variable called sessionMap in BaseStrutsTestCase. And then in the createAction method, issue the statement: proxy.getInvocation().getInvocationContext().setSession(sessionMap); Hope that helps. The only other fringe case that I have dealth with in our code, is when we have actions that implement Preparable and are used with a ParamsPrepareParams interceptor. I created a method to allow action parameters to be set. /** * Sets the action parameters * @param parameters Parameters to set */ protected void setActionParameters(MapString, String parameters) { proxy.getInvocation().getInvocationContext(). setParameters(parameters); } Then inside my Action Test class, I can issue: proxy.setActionParameters(...); before: proxy.execute(); Cheers, -- Haroon Rafique haroon.rafi...@utoronto.ca - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
On Today at 2:02pm, DC=Dimitrios Christodoulakis dimi@gmail.com wrote: DC [..snip..] DC DC The CONFIG_LOCATIONS is used to initialize the servletContext which in DC turn is used to initialize the applicationContext, right? So, I am not DC sure where is the correct place to add the web.xml file, or how to DC tell BaseStrutsTestCase to include OpenEntityManagerInViewFilter DC during the recreation of the framework. DC The CONFIG_LOCATIONS variable is used to initialize spring only. I don't use spring-orm, so I can't comment on how to tell BaseStrutsTestCase to include that particular filter (or any other filter for that matter). DC DC Is that a limitation of this test class, or I am trying to include my DC web.xml file the wrong way? DC Most probably a limitation. DC DC I am not sure if other folks using this example code dealt with DC something like this in the past and solved it. Haroon, I hope you DC don't mind my asking you again about this :) DC DC Also, a more general question: Can the proxy class be used to create DC and run two actions sequentially? Let's say I want to test an action DC in my secure namespace, meaning that some sort of login or DC registration action comes first. DC I think you're over-stepping the bounds of unit testing here. In any case, I have created multiple invocations of the same action in the same test method without any problems. E.g., createAction(SomeAction.class, /namespace, actionName); //... set some parameters assertEquals(SUCCESS, proxy.execute()); //create action again createAction(SomeAction.class, /namespace, actionName); //... set some *different* parameters so that we expect INPUT to be // returned assertEquals(INPUT, proxy.execute()); There's nothing to prevent you from recreating another Action all together. You just have to remember that every time you execute createAction, it creates a new mock request and mock response, so you have to populate things properly. DC DC So, could I do something like this in my test method?: DC In your code below, where you say // and then execute proxy again, are you missing some stepls where you need to supply some parameters to the action? DC DC @Test DC public void testExecute() throws Exception{ DC Login testLogin = createAction(Login.class, /, Login); DC //set my fields DC testLogin.setPassword(...); DC //execute proxy once DC proxy.execute(); DC //Then create my secure action DC UpdateProfile testUpdateProfile = DC createAction(UpdateProfile.class, /secure, UpdateProfile); DC //and then execute proxy again DC proxy.execute(); DC } DC DC [..snip..] DC DC Up until now I manually created mock objects to satisfy any DC dependencies of the class under test: Created a user object and put in DC on a Session map manually to simulate a successful login action. So DC the motive here was to use this example test code to actually create DC and execute a successful test of the predecessor action (so the login DC action itself could add the logged in user to the session) before the DC actual action that I am primarily testing (updateProfile). DC Smells like functional testing to me. DC DC Anyway, I sure hope I am not stretching this conversation too far by DC experimenting a bit further with this example. Any suggestions are DC appreciated. DC DC Regards. Cheers, -- Haroon Rafique haroon.rafi...@utoronto.ca - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
In your code below, where you say // and then execute proxy again, are you missing some stepls where you need to supply some parameters to the action? Yes, that wasn't actual code, just the steps I was considering. -In any case it's good to know the limitations of the example. You are right, sometimes I need to test a broader unit of work, which can include a couple of actions, rather than just one. So, in that sense, I could be stepping into the functional testing area. I appreciate all the helpful information. I've already learned a lot, by the example code, and the discussions on this thread! On Tue, Jul 21, 2009 at 3:31 PM, Haroon Rafiqueharoon.rafi...@utoronto.ca wrote: On Today at 2:02pm, DC=Dimitrios Christodoulakis dimi@gmail.com wrote: DC [..snip..] DC DC The CONFIG_LOCATIONS is used to initialize the servletContext which in DC turn is used to initialize the applicationContext, right? So, I am not DC sure where is the correct place to add the web.xml file, or how to DC tell BaseStrutsTestCase to include OpenEntityManagerInViewFilter DC during the recreation of the framework. DC The CONFIG_LOCATIONS variable is used to initialize spring only. I don't use spring-orm, so I can't comment on how to tell BaseStrutsTestCase to include that particular filter (or any other filter for that matter). DC DC Is that a limitation of this test class, or I am trying to include my DC web.xml file the wrong way? DC Most probably a limitation. DC DC I am not sure if other folks using this example code dealt with DC something like this in the past and solved it. Haroon, I hope you DC don't mind my asking you again about this :) DC DC Also, a more general question: Can the proxy class be used to create DC and run two actions sequentially? Let's say I want to test an action DC in my secure namespace, meaning that some sort of login or DC registration action comes first. DC I think you're over-stepping the bounds of unit testing here. In any case, I have created multiple invocations of the same action in the same test method without any problems. E.g., createAction(SomeAction.class, /namespace, actionName); //... set some parameters assertEquals(SUCCESS, proxy.execute()); //create action again createAction(SomeAction.class, /namespace, actionName); //... set some *different* parameters so that we expect INPUT to be // returned assertEquals(INPUT, proxy.execute()); There's nothing to prevent you from recreating another Action all together. You just have to remember that every time you execute createAction, it creates a new mock request and mock response, so you have to populate things properly. DC DC So, could I do something like this in my test method?: DC In your code below, where you say // and then execute proxy again, are you missing some stepls where you need to supply some parameters to the action? DC DC @Test DC public void testExecute() throws Exception{ DC Login testLogin = createAction(Login.class, /, Login); DC //set my fields DC testLogin.setPassword(...); DC //execute proxy once DC proxy.execute(); DC //Then create my secure action DC UpdateProfile testUpdateProfile = DC createAction(UpdateProfile.class, /secure, UpdateProfile); DC //and then execute proxy again DC proxy.execute(); DC } DC DC [..snip..] DC DC Up until now I manually created mock objects to satisfy any DC dependencies of the class under test: Created a user object and put in DC on a Session map manually to simulate a successful login action. So DC the motive here was to use this example test code to actually create DC and execute a successful test of the predecessor action (so the login DC action itself could add the logged in user to the session) before the DC actual action that I am primarily testing (updateProfile). DC Smells like functional testing to me. DC DC Anyway, I sure hope I am not stretching this conversation too far by DC experimenting a bit further with this example. Any suggestions are DC appreciated. DC DC Regards. Cheers, -- Haroon Rafique haroon.rafi...@utoronto.ca - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
On Yesterday at 9:16pm, DC=Dimitrios Christodoulakis dimi@gmail.com...: DC [..snip..] DC DC When testing (junit 4) an action implementing the Sessionaware DC interface (my login and register classes) I noticed that the session DC object is set to null by BaseStrutsTestCase. This was mentioned before DC in the author's blog, but not sure if ever addressed. I added a new DC comment over there but the discussion could be inactive. DC Hi Dimitrios, Don't think arsenalist is watching that blog dilligently any more. DC DC I was wondering if anyone who is using the BaseStrutsTestCase, or used DC it in the past, came across this issue and if by any chance managed to DC resolve it. Perhaps Haroon might have a comment on this? DC Not a whole lot at the moment as none of our Action classes implement those interfaces. How about something like: protected static HashMap sessionMap = new HashMap(); // and further on later in the code proxy.getInvocation().getInvocationContext().setSession(sessionMap); DC DC Also, a couple of more general questions: DC DC 1) Is there a recommended way to check during testing which DCinterceptors are firing and when? DC Careful there. Haven't you now delved into the territory of testing the framework itself (rather than your own code)? IMHO, I would assume that it's the framework's responsibility to make sure that when a certain set of interceptors is configured, they better fire properly. DC DC [..snip..] DC DC Kind regards and I appreciate all the input. DC Cheers, -- Haroon Rafique haroon.rafi...@utoronto.ca - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Thanks Haroon for the handy advice. That seems to do the trick as far as the session object is concerned. The test passes now. Would it be easy for someone to extend your code to include actions that implement the -aware interfaces? If I wanted to take a shot at that, is there a particular point you would suggest I start with? Also, many thanks to Wes, for pointing out a good starting point for understanding Struts2 at a deeper level by examining the code! Regards to all. On Mon, Jul 20, 2009 at 9:26 AM, Haroon Rafiqueharoon.rafi...@utoronto.ca wrote: On Yesterday at 9:16pm, DC=Dimitrios Christodoulakis dimi@gmail.com...: DC [..snip..] DC DC When testing (junit 4) an action implementing the Sessionaware DC interface (my login and register classes) I noticed that the session DC object is set to null by BaseStrutsTestCase. This was mentioned before DC in the author's blog, but not sure if ever addressed. I added a new DC comment over there but the discussion could be inactive. DC Hi Dimitrios, Don't think arsenalist is watching that blog dilligently any more. DC DC I was wondering if anyone who is using the BaseStrutsTestCase, or used DC it in the past, came across this issue and if by any chance managed to DC resolve it. Perhaps Haroon might have a comment on this? DC Not a whole lot at the moment as none of our Action classes implement those interfaces. How about something like: protected static HashMap sessionMap = new HashMap(); // and further on later in the code proxy.getInvocation().getInvocationContext().setSession(sessionMap); DC DC Also, a couple of more general questions: DC DC 1) Is there a recommended way to check during testing which DC interceptors are firing and when? DC Careful there. Haven't you now delved into the territory of testing the framework itself (rather than your own code)? IMHO, I would assume that it's the framework's responsibility to make sure that when a certain set of interceptors is configured, they better fire properly. DC DC [..snip..] DC DC Kind regards and I appreciate all the input. DC Cheers, -- Haroon Rafique haroon.rafi...@utoronto.ca - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
On Today at 4:32pm, DC=Dimitrios Christodoulakis dimi@gmail.com wrote: DC Thanks Haroon for the handy advice. That seems to do the trick as far DC as the session object is concerned. The test passes now. DC Glad it worked out. DC DC Would it be easy for someone to extend your code to include actions DC that implement the -aware interfaces? If I wanted to take a shot at DC that, is there a particular point you would suggest I start with? DC Did you add that code in your Test class? I was actually suggesting that you modify the code inside BaseStrutsTestCase. So, I would recommend adding a private static HashMap variable called sessionMap in BaseStrutsTestCase. And then in the createAction method, issue the statement: proxy.getInvocation().getInvocationContext().setSession(sessionMap); Hope that helps. The only other fringe case that I have dealth with in our code, is when we have actions that implement Preparable and are used with a ParamsPrepareParams interceptor. I created a method to allow action parameters to be set. /** * Sets the action parameters * @param parameters Parameters to set */ protected void setActionParameters(MapString, String parameters) { proxy.getInvocation().getInvocationContext(). setParameters(parameters); } Then inside my Action Test class, I can issue: proxy.setActionParameters(...); before: proxy.execute(); Cheers, -- Haroon Rafique haroon.rafi...@utoronto.ca - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Thanks for clarifying Haroon, Actually the additions you are mentioning sum up the original testing code pretty well. Like I said, from an educational point of view, I think one can learn a lot about the framework itself by studying that article and the comments. Thanks for the preparable bit too. As other folks here mentioned, it depends on the testing requirements of the project when it comes which test strategy to take, or which tool to use. As a learner, I found it very useful to experiment with that code. I haven't tried Selenium yet, but I would be interested to see how it catches the same errors in the same test cases. On Mon, Jul 20, 2009 at 5:02 PM, Haroon Rafiqueharoon.rafi...@utoronto.ca wrote: On Today at 4:32pm, DC=Dimitrios Christodoulakis dimi@gmail.com wrote: DC Thanks Haroon for the handy advice. That seems to do the trick as far DC as the session object is concerned. The test passes now. DC Glad it worked out. DC DC Would it be easy for someone to extend your code to include actions DC that implement the -aware interfaces? If I wanted to take a shot at DC that, is there a particular point you would suggest I start with? DC Did you add that code in your Test class? I was actually suggesting that you modify the code inside BaseStrutsTestCase. So, I would recommend adding a private static HashMap variable called sessionMap in BaseStrutsTestCase. And then in the createAction method, issue the statement: proxy.getInvocation().getInvocationContext().setSession(sessionMap); Hope that helps. The only other fringe case that I have dealth with in our code, is when we have actions that implement Preparable and are used with a ParamsPrepareParams interceptor. I created a method to allow action parameters to be set. /** * Sets the action parameters * @param parameters Parameters to set */ protected void setActionParameters(MapString, String parameters) { proxy.getInvocation().getInvocationContext(). setParameters(parameters); } Then inside my Action Test class, I can issue: proxy.setActionParameters(...); before: proxy.execute(); Cheers, -- Haroon Rafique haroon.rafi...@utoronto.ca - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: unit testing Struts2 application (with Spring and Hibernate)
can you show the code to obtain proxy? could you post the URL for article? Merci Martin Gainty __ Note de déni et de confidentialité Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Mon, 20 Jul 2009 19:07:09 -0500 Subject: Re: unit testing Struts2 application (with Spring and Hibernate) From: dimi@gmail.com To: user@struts.apache.org Thanks for clarifying Haroon, Actually the additions you are mentioning sum up the original testing code pretty well. Like I said, from an educational point of view, I think one can learn a lot about the framework itself by studying that article and the comments. Thanks for the preparable bit too. As other folks here mentioned, it depends on the testing requirements of the project when it comes which test strategy to take, or which tool to use. As a learner, I found it very useful to experiment with that code. I haven't tried Selenium yet, but I would be interested to see how it catches the same errors in the same test cases. On Mon, Jul 20, 2009 at 5:02 PM, Haroon Rafiqueharoon.rafi...@utoronto.ca wrote: On Today at 4:32pm, DC=Dimitrios Christodoulakis dimi@gmail.com wrote: DC Thanks Haroon for the handy advice. That seems to do the trick as far DC as the session object is concerned. The test passes now. DC Glad it worked out. DC DC Would it be easy for someone to extend your code to include actions DC that implement the -aware interfaces? If I wanted to take a shot at DC that, is there a particular point you would suggest I start with? DC Did you add that code in your Test class? I was actually suggesting that you modify the code inside BaseStrutsTestCase. So, I would recommend adding a private static HashMap variable called sessionMap in BaseStrutsTestCase. And then in the createAction method, issue the statement: proxy.getInvocation().getInvocationContext().setSession(sessionMap); Hope that helps. The only other fringe case that I have dealth with in our code, is when we have actions that implement Preparable and are used with a ParamsPrepareParams interceptor. I created a method to allow action parameters to be set. /** * Sets the action parameters * @param parameters Parameters to set */ protected void setActionParameters(MapString, String parameters) { proxy.getInvocation().getInvocationContext(). setParameters(parameters); } Then inside my Action Test class, I can issue: proxy.setActionParameters(...); before: proxy.execute(); Cheers, -- Haroon Rafique haroon.rafi...@utoronto.ca - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org _ Windows Live™ Hotmail®: Celebrate the moment with your favorite sports pics. Check it out. http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_WL_QA_HM_sports_photos_072009cat=sports
Re: unit testing Struts2 application (with Spring and Hibernate)
The full article is here: http://depressedprogrammer.wordpress.com/2007/06/18/unit-testing-struts-2-actions-spring-junit/ I think the author's explanations cover a lot. The comments and the subsequent conversations are of value too. On Mon, Jul 20, 2009 at 7:33 PM, Martin Gaintymgai...@hotmail.com wrote: can you show the code to obtain proxy? could you post the URL for article? Merci Martin Gainty __ Note de déni et de confidentialité Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Mon, 20 Jul 2009 19:07:09 -0500 Subject: Re: unit testing Struts2 application (with Spring and Hibernate) From: dimi@gmail.com To: user@struts.apache.org Thanks for clarifying Haroon, Actually the additions you are mentioning sum up the original testing code pretty well. Like I said, from an educational point of view, I think one can learn a lot about the framework itself by studying that article and the comments. Thanks for the preparable bit too. As other folks here mentioned, it depends on the testing requirements of the project when it comes which test strategy to take, or which tool to use. As a learner, I found it very useful to experiment with that code. I haven't tried Selenium yet, but I would be interested to see how it catches the same errors in the same test cases. On Mon, Jul 20, 2009 at 5:02 PM, Haroon Rafiqueharoon.rafi...@utoronto.ca wrote: On Today at 4:32pm, DC=Dimitrios Christodoulakis dimi@gmail.com wrote: DC Thanks Haroon for the handy advice. That seems to do the trick as far DC as the session object is concerned. The test passes now. DC Glad it worked out. DC DC Would it be easy for someone to extend your code to include actions DC that implement the -aware interfaces? If I wanted to take a shot at DC that, is there a particular point you would suggest I start with? DC Did you add that code in your Test class? I was actually suggesting that you modify the code inside BaseStrutsTestCase. So, I would recommend adding a private static HashMap variable called sessionMap in BaseStrutsTestCase. And then in the createAction method, issue the statement: proxy.getInvocation().getInvocationContext().setSession(sessionMap); Hope that helps. The only other fringe case that I have dealth with in our code, is when we have actions that implement Preparable and are used with a ParamsPrepareParams interceptor. I created a method to allow action parameters to be set. /** * Sets the action parameters * @param parameters Parameters to set */ protected void setActionParameters(MapString, String parameters) { proxy.getInvocation().getInvocationContext(). setParameters(parameters); } Then inside my Action Test class, I can issue: proxy.setActionParameters(...); before: proxy.execute(); Cheers, -- Haroon Rafique haroon.rafi...@utoronto.ca - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org _ Windows Live™ Hotmail®: Celebrate the moment with your favorite sports pics. Check it out. http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_WL_QA_HM_sports_photos_072009cat=sports - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
[The standard?diclaimer that it is not a popularity contest and nothing that does the job for you is wrong.] Would you not agree that if you are going to mock up the framework the simulation of S2 of highest fidelity is S2 itself. IMHO?you are digging a swimming pool by the ocean to test your yatch. I am not familiar with Selenium but anything you can do with JUnit you can do in JWebUnit since it is just JUnit with more libraries. I took your route or instantiating parts of S2 in standard JUnit tests and run into trouble when I moved from 2,0,x to 2,1,x due to changes in the framework. It is a bummer when you switch versions and find the tests are dead. Chris -Original Message- From: Greg Lindholm greg.lindh...@gmail.com To: Struts Users Mailing List user@struts.apache.org Sent: Sat, Jul 18, 2009 3:00 am Subject: Re: unit testing Struts2 application (with Spring and Hibernate) IMO that's outside the purview of unit testing, though--by definition this describes integration testing: the testing of an action along with the framework. There's nothing *wrong* with doing that testing, I just don't think it's the same thing as unit testing: independently testing the smallest bits of functionality. JUnit can be used for that kind of testing too (and I do, sometimes), but once I'm at that point I generally figure I might as well just be doing client-focused testing and testing the output of my results. I also use Selenium, although I may switch back to using a layer I wrote on top of Watir. Dave Not to throw weight around, but it is sort of curious to me that the three struts committers who chimed in all agreed that tip-to-tail integration testing in JUnit is not worth the effort. I only bring it up because, IMO, struts 2 is one of the best-unit-tested products I've ever worked on. I think Dave, Musachy and myself are biased against tip-to-tail in JUnit because in Struts 2, we have a guideline to unit test all bugfixes and new functionality. That being so, all three of us have probably come across situations where writing the unit test is 500x harder than writing the fix :) Dave does a good job of making the point I tried to make earlier, tip-to-tail testing is better looked at as an integration test and it becomes much easier to deal with as an integration test. If you are unfamiliar with selenium, it is worth learning. One of the posters earlier mentioned that he didn't want to learn another testing framework when he already knows JUnit. Selenium is nice because it runs right in the browser (IE and Firefox) and runs though a set of VB-like instructions... Things like - open this url, look for this text, click this link and then make sure this text exists. IMO, if you want to make sure th at your action renders the appropriate result, this is way better than trying to coax the framework by bootstrapping it with mocks then figuring out a way to retrieve the rendered result. As an added bonus, it is possible to get maven to launch selenium tests, so you can get full unit and integration testing out of your CI if you are willing to put forth the effort. To drive the point home further, I would add that the Dojo plugin probably would have been more stable if we had taken the selenium approach (that is being employed with the slowly moving jquery plugin). -Wes Not to pick on anyone but this isn't really a popularity contest. Different situations have different needs and there is no reason to suggest that one solution will work best for everyone. At a large shop naming something unit testing vs integration testing maybe important as it can determined who's job it is to do the work. But at a small shop, like I'm at, it makes no difference, it's all just testing and it's the developers job. So for me, whatever way is easiest, quickest and gets the job done wins. It took some work at first to figure out how to tests actions with the full stack with junit but now that I have the plumbing figured out it's very easy to add tests as actions are added. With junit I can easily set the database to a know state before each test, or use mocks to simulate hard to setup edge conditions (how easy is that to do with selenium?) Plus it's easy to jun junit with code coverage so I can see code isn't being covered. And, as another already pointed out, junit is fast and convienent, 2 clicks from inside Eclipse. I do think it is great to see that the industry (at least those on this list) recognizes the importance of automated testing and that with Struts you have ability to test at the isolated pojo detail level all the way through full blow integration testing.
Re: unit testing Struts2 application (with Spring and Hibernate)
Hi all, [the standard disclaimer ... ;-) ] migrating from one version of struts to another is not a trouble for selenium or such a tool, actually it even helps You to be sure that the migration didn't break anything. But You will hit the same scale of problems when You will change layout - all selenium tests are dead, of course one may argue that he is able to write selenium tests that way that it will stay alive but that will be extra effort to cope with that. Every solution have it's own set of troubles involved. The is no better way, i think. We can point out pros and cons of solutions we use, so that others could make theirs decisions based on our experiences. Best greetings, Paweł Wielgus. 2009/7/19 musom...@aol.com: [The standard?diclaimer that it is not a popularity contest and nothing that does the job for you is wrong.] Would you not agree that if you are going to mock up the framework the simulation of S2 of highest fidelity is S2 itself. IMHO?you are digging a swimming pool by the ocean to test your yatch. I am not familiar with Selenium but anything you can do with JUnit you can do in JWebUnit since it is just JUnit with more libraries. I took your route or instantiating parts of S2 in standard JUnit tests and run into trouble when I moved from 2,0,x to 2,1,x due to changes in the framework. It is a bummer when you switch versions and find the tests are dead. Chris -Original Message- From: Greg Lindholm greg.lindh...@gmail.com To: Struts Users Mailing List user@struts.apache.org Sent: Sat, Jul 18, 2009 3:00 am Subject: Re: unit testing Struts2 application (with Spring and Hibernate) IMO that's outside the purview of unit testing, though--by definition this describes integration testing: the testing of an action along with the framework. There's nothing *wrong* with doing that testing, I just don't think it's the same thing as unit testing: independently testing the smallest bits of functionality. JUnit can be used for that kind of testing too (and I do, sometimes), but once I'm at that point I generally figure I might as well just be doing client-focused testing and testing the output of my results. I also use Selenium, although I may switch back to using a layer I wrote on top of Watir. Dave Not to throw weight around, but it is sort of curious to me that the three struts committers who chimed in all agreed that tip-to-tail integration testing in JUnit is not worth the effort. I only bring it up because, IMO, struts 2 is one of the best-unit-tested products I've ever worked on. I think Dave, Musachy and myself are biased against tip-to-tail in JUnit because in Struts 2, we have a guideline to unit test all bugfixes and new functionality. That being so, all three of us have probably come across situations where writing the unit test is 500x harder than writing the fix :) Dave does a good job of making the point I tried to make earlier, tip-to-tail testing is better looked at as an integration test and it becomes much easier to deal with as an integration test. If you are unfamiliar with selenium, it is worth learning. One of the posters earlier mentioned that he didn't want to learn another testing framework when he already knows JUnit. Selenium is nice because it runs right in the browser (IE and Firefox) and runs though a set of VB-like instructions... Things like - open this url, look for this text, click this link and then make sure this text exists. IMO, if you want to make sure th at your action renders the appropriate result, this is way better than trying to coax the framework by bootstrapping it with mocks then figuring out a way to retrieve the rendered result. As an added bonus, it is possible to get maven to launch selenium tests, so you can get full unit and integration testing out of your CI if you are willing to put forth the effort. To drive the point home further, I would add that the Dojo plugin probably would have been more stable if we had taken the selenium approach (that is being employed with the slowly moving jquery plugin). -Wes Not to pick on anyone but this isn't really a popularity contest. Different situations have different needs and there is no reason to suggest that one solution will work best for everyone. At a large shop naming something unit testing vs integration testing maybe important as it can determined who's job it is to do the work. But at a small shop, like I'm at, it makes no difference, it's all just testing and it's the developers job. So for me, whatever way is easiest, quickest and gets the job done wins. It took some work at first to figure out how to tests actions with the full stack with junit but now that I have the plumbing figured out it's very easy to add tests as actions are added. With junit I can easily set the database to a know state before
Re: unit testing Struts2 application (with Spring and Hibernate)
Paweł Wielgus wrote: But You will hit the same scale of problems when You will change layout - all selenium tests are dead, I haven't really found that to be the case--I only rarely test deep structure with Selenium, but instead look for the presence of specific CSS selectors containing text etc. That type of change is (generally) under my control, unlike a framework change that breaks *my* tests. Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Hi Dave, when i record my tests with selenium ide, all click or assert alements takes various loactor addresses, very often they contain DOM paths, so when layout is changed from tables to divs, all these addresses are no longer valid. To present one simple example, when i record logout click on one of my sites the recorded command i see is clickAndWait //strong instead of clickAndWait link=logout i know this is plain wrong and i could manualy correct it but it ilustrates the problem. So when the layout will change and this logout will not be the first element that is strong, which is very probable, this test will fail to click the logout link. I have done about 3 such huge layout changes and every time it involved tests update. Still, i use and promote selenium over junit for that kind of job. Best greetings, Paweł Wielgus. 2009/7/19 Dave Newton newton.d...@yahoo.com: Paweł Wielgus wrote: But You will hit the same scale of problems when You will change layout - all selenium tests are dead, I haven't really found that to be the case--I only rarely test deep structure with Selenium, but instead look for the presence of specific CSS selectors containing text etc. That type of change is (generally) under my control, unlike a framework change that breaks *my* tests. Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Paweł Wielgus wrote: Hi Dave, when i record my tests with selenium ide, all click or assert alements takes various loactor addresses, very often they contain DOM paths, so when layout is changed from tables to divs, all these addresses are no longer valid. On the rare occasions I use the IDE to generate the script I find I always modify it pretty heavily--since I am pretty good about marking up my HTML it's almost easier to just write the tests by hand so I can target only the most-specific elements I'm looking for. I'm rarely bitten by layout changes since the important stuff doesn't change much regardless of its surroundings. YMMV :) Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Primarily for the sake of learning the inner mechanics of the struts2 framework, and unit testing, I took some time to study and experiment with the code published at: http://depressedprogrammer.wordpress.com/2007/06/18/unit-testing-struts-2-actions-spring-junit/ When testing (junit 4) an action implementing the Sessionaware interface (my login and register classes) I noticed that the session object is set to null by BaseStrutsTestCase. This was mentioned before in the author's blog, but not sure if ever addressed. I added a new comment over there but the discussion could be inactive. I was wondering if anyone who is using the BaseStrutsTestCase, or used it in the past, came across this issue and if by any chance managed to resolve it. Perhaps Haroon might have a comment on this? Also, a couple of more general questions: 1) Is there a recommended way to check during testing which interceptors are firing and when? 2) If one with general knowledge of servlets jsp wants to dive into the struts2 source code, to get better understanding of the basic mechanics, what would be the starting point? So should I start lets say with the struts.core package?, which would be the entry point class Despatcher, then ActionProxy? -- To the untrained eye (myself), when looking the code from a distance (http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/), it looks somewhat like a ball of twine, so where should I look for the piece of string that sticks out and will help me untangle it? Well, the primary objective is testing our struts2 application, so I will probably try other approaches mentioned in this discussion. So, I would like to take a deeper look at Selenium next. Kind regards and I appreciate all the input. On Sun, Jul 19, 2009 at 4:35 PM, Dave Newtonnewton.d...@yahoo.com wrote: Paweł Wielgus wrote: Hi Dave, when i record my tests with selenium ide, all click or assert alements takes various loactor addresses, very often they contain DOM paths, so when layout is changed from tables to divs, all these addresses are no longer valid. On the rare occasions I use the IDE to generate the script I find I always modify it pretty heavily--since I am pretty good about marking up my HTML it's almost easier to just write the tests by hand so I can target only the most-specific elements I'm looking for. I'm rarely bitten by layout changes since the important stuff doesn't change much regardless of its surroundings. YMMV :) Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
On Sunday 19 July 2009 10:16:59 pm Dimitrios Christodoulakis wrote: 2) If one with general knowledge of servlets jsp wants to dive into the struts2 source code, to get better understanding of the basic mechanics, what would be the starting point? So should I start lets say with the struts.core package?, which would be the entry point class Despatcher, then ActionProxy? -- To the untrained eye (myself), when looking the code from a distance (http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/), it looks somewhat like a ball of twine, so where should I look for the piece of string that sticks out and will help me untangle it? Depending on your goals, I think one place to start might be the xwork core. Xwork is an implementation of the command design pattern... http://en.wikipedia.org/wiki/Command_Pattern Once you have a solid understanding of what is going on within xwork, then you can start with the Dispatcher. That being said, Struts is really the combination of many things. For instance, it lets xwork drive the core flow of request processing, but there is also the tag library. The tag library does a good job of breaking up processing into models, templating and jsp tag specific stuff. If you are interested in the tag library, start with Component and take a look at a few of the easier to follow tags (s:if, s:url, etc.). Part of understanding the tag library means learning freemarker, but freemarker is easy to learn as you go. -Wes -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Hi all, while i do selenium tests and i do prefer it for integration tests, i'm feeling obligated to point out one disadvantage, while being very easy and fun to write or record, they tend to take a lot more time to run in comparison to unit tests. My case is tons of selenium tests which takes about 45 minutes when run in paralel. But that's just my case which is very special, i test whole stories on many apps at the same time. On the pros side i have confidence that all my business processes are doing well. Best greetings, Paweł Wielgus. 2009/7/17 Wes Wannemacher w...@wantii.com: On Thursday 16 July 2009 07:14:30 pm Dave Newton wrote: IMO that's outside the purview of unit testing, though--by definition this describes integration testing: the testing of an action along with the framework. There's nothing *wrong* with doing that testing, I just don't think it's the same thing as unit testing: independently testing the smallest bits of functionality. JUnit can be used for that kind of testing too (and I do, sometimes), but once I'm at that point I generally figure I might as well just be doing client-focused testing and testing the output of my results. I also use Selenium, although I may switch back to using a layer I wrote on top of Watir. Dave Not to throw weight around, but it is sort of curious to me that the three struts committers who chimed in all agreed that tip-to-tail integration testing in JUnit is not worth the effort. I only bring it up because, IMO, struts 2 is one of the best-unit-tested products I've ever worked on. I think Dave, Musachy and myself are biased against tip-to-tail in JUnit because in Struts 2, we have a guideline to unit test all bugfixes and new functionality. That being so, all three of us have probably come across situations where writing the unit test is 500x harder than writing the fix :) Dave does a good job of making the point I tried to make earlier, tip-to-tail testing is better looked at as an integration test and it becomes much easier to deal with as an integration test. If you are unfamiliar with selenium, it is worth learning. One of the posters earlier mentioned that he didn't want to learn another testing framework when he already knows JUnit. Selenium is nice because it runs right in the browser (IE and Firefox) and runs though a set of VB-like instructions... Things like - open this url, look for this text, click this link and then make sure this text exists. IMO, if you want to make sure that your action renders the appropriate result, this is way better than trying to coax the framework by bootstrapping it with mocks then figuring out a way to retrieve the rendered result. As an added bonus, it is possible to get maven to launch selenium tests, so you can get full unit and integration testing out of your CI if you are willing to put forth the effort. To drive the point home further, I would add that the Dojo plugin probably would have been more stable if we had taken the selenium approach (that is being employed with the slowly moving jquery plugin). -Wes -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
JWebUnit integrates? nicely with eclipse. I fall in the?'unit tests are for small? units' group. If your validation is configured wrong you won't fix it in the action so you are not really unit testing the action at that point. I prefer separate JUnit unit tests and JWebUnit tests to test the whole enchilada. Chris -Original Message- From: Wes Wannemacher w...@wantii.com To: Struts Users Mailing List user@struts.apache.org Sent: Fri, Jul 17, 2009 10:59 am Subject: Re: unit testing Struts2 application (with Spring and Hibernate) On Thursday 16 July 2009 07:14:30 pm Dave Newton wrote: IMO that's outside the purview of unit testing, though--by definition this describes integration testing: the testing of an action along with the framework. There's nothing *wrong* with doing that testing, I just don't think it's the same thing as unit testing: independently testing the smallest bits of functionality. JUnit can be used for that kind of testing too (and I do, sometimes), but once I'm at that point I generally figure I might as well just be doing client-focused testing and testing the output of my results. I also use Selenium, although I may switch back to using a layer I wrote on top of Watir. Dave Not to throw weight around, but it is sort of curious to me that the three struts committers who chimed in all agreed that tip-to-tail integration testing in JUnit is not worth the effort. I only bring it up because, IMO, struts 2 is one of the best-unit-tested products I've ever worked on. I think Dave, Musachy and myself are biased against tip-to-tail in JUnit because in Struts 2, we have a guideline to unit test all bugfixes and new functionality. That being so, all three of us have probably come across situations where writing the unit test is 500x harder than writing the fix :) Dave does a good job of making the point I tried to make earlier, tip-to-tail testing is better looked at as an integration test and it becomes much easier to deal with as an integration test. If you are unfamiliar with selenium, it is worth learning. One of the posters earlier mentioned that he didn't want to learn another testing framework when he already knows JUnit. Selenium is nice because it runs right in the browser (IE and Firefox) and runs though a set of VB-like instructions... Things like - open this url, look for this text, click this link and then make sure this text exists. IMO, if you want to make sure that your action renders the appropriate result, this is way better than trying to coax the framework by bootstrapping it with mocks then figuring out a way to retrieve the rendered result. As an added bonus, it is possible to get maven to launch selenium tests, so you can get full unit and integration testing out of your CI if you are willing to put forth the effort. To drive the point home further, I would add that the Dojo plugin probably would have been more stable if we had taken the selenium approach (that is being employed with the slowly moving jquery plugin). -Wes -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: unit testing Struts2 application (with Spring and Hibernate)
Couldn't agree more. From: w...@wantii.com To: user@struts.apache.org Subject: Re: unit testing Struts2 application (with Spring and Hibernate) Date: Thu, 16 Jul 2009 21:59:35 -0400 On Thursday 16 July 2009 07:14:30 pm Dave Newton wrote: IMO that's outside the purview of unit testing, though--by definition this describes integration testing: the testing of an action along with the framework. There's nothing *wrong* with doing that testing, I just don't think it's the same thing as unit testing: independently testing the smallest bits of functionality. JUnit can be used for that kind of testing too (and I do, sometimes), but once I'm at that point I generally figure I might as well just be doing client-focused testing and testing the output of my results. I also use Selenium, although I may switch back to using a layer I wrote on top of Watir. Dave Not to throw weight around, but it is sort of curious to me that the three struts committers who chimed in all agreed that tip-to-tail integration testing in JUnit is not worth the effort. I only bring it up because, IMO, struts 2 is one of the best-unit-tested products I've ever worked on. I think Dave, Musachy and myself are biased against tip-to-tail in JUnit because in Struts 2, we have a guideline to unit test all bugfixes and new functionality. That being so, all three of us have probably come across situations where writing the unit test is 500x harder than writing the fix :) Dave does a good job of making the point I tried to make earlier, tip-to-tail testing is better looked at as an integration test and it becomes much easier to deal with as an integration test. If you are unfamiliar with selenium, it is worth learning. One of the posters earlier mentioned that he didn't want to learn another testing framework when he already knows JUnit. Selenium is nice because it runs right in the browser (IE and Firefox) and runs though a set of VB-like instructions... Things like - open this url, look for this text, click this link and then make sure this text exists. IMO, if you want to make sure that your action renders the appropriate result, this is way better than trying to coax the framework by bootstrapping it with mocks then figuring out a way to retrieve the rendered result. As an added bonus, it is possible to get maven to launch selenium tests, so you can get full unit and integration testing out of your CI if you are willing to put forth the effort. To drive the point home further, I would add that the Dojo plugin probably would have been more stable if we had taken the selenium approach (that is being employed with the slowly moving jquery plugin). -Wes -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org _ Hotmail® has ever-growing storage! Don’t worry about storage limits. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009
Re: unit testing Struts2 application (with Spring and Hibernate)
IMO that's outside the purview of unit testing, though--by definition this describes integration testing: the testing of an action along with the framework. There's nothing *wrong* with doing that testing, I just don't think it's the same thing as unit testing: independently testing the smallest bits of functionality. JUnit can be used for that kind of testing too (and I do, sometimes), but once I'm at that point I generally figure I might as well just be doing client-focused testing and testing the output of my results. I also use Selenium, although I may switch back to using a layer I wrote on top of Watir. Dave Not to throw weight around, but it is sort of curious to me that the three struts committers who chimed in all agreed that tip-to-tail integration testing in JUnit is not worth the effort. I only bring it up because, IMO, struts 2 is one of the best-unit-tested products I've ever worked on. I think Dave, Musachy and myself are biased against tip-to-tail in JUnit because in Struts 2, we have a guideline to unit test all bugfixes and new functionality. That being so, all three of us have probably come across situations where writing the unit test is 500x harder than writing the fix :) Dave does a good job of making the point I tried to make earlier, tip-to-tail testing is better looked at as an integration test and it becomes much easier to deal with as an integration test. If you are unfamiliar with selenium, it is worth learning. One of the posters earlier mentioned that he didn't want to learn another testing framework when he already knows JUnit. Selenium is nice because it runs right in the browser (IE and Firefox) and runs though a set of VB-like instructions... Things like - open this url, look for this text, click this link and then make sure this text exists. IMO, if you want to make sure that your action renders the appropriate result, this is way better than trying to coax the framework by bootstrapping it with mocks then figuring out a way to retrieve the rendered result. As an added bonus, it is possible to get maven to launch selenium tests, so you can get full unit and integration testing out of your CI if you are willing to put forth the effort. To drive the point home further, I would add that the Dojo plugin probably would have been more stable if we had taken the selenium approach (that is being employed with the slowly moving jquery plugin). -Wes Not to pick on anyone but this isn't really a popularity contest. Different situations have different needs and there is no reason to suggest that one solution will work best for everyone. At a large shop naming something unit testing vs integration testing maybe important as it can determined who's job it is to do the work. But at a small shop, like I'm at, it makes no difference, it's all just testing and it's the developers job. So for me, whatever way is easiest, quickest and gets the job done wins. It took some work at first to figure out how to tests actions with the full stack with junit but now that I have the plumbing figured out it's very easy to add tests as actions are added. With junit I can easily set the database to a know state before each test, or use mocks to simulate hard to setup edge conditions (how easy is that to do with selenium?) Plus it's easy to jun junit with code coverage so I can see code isn't being covered. And, as another already pointed out, junit is fast and convienent, 2 clicks from inside Eclipse. I do think it is great to see that the industry (at least those on this list) recognizes the importance of automated testing and that with Struts you have ability to test at the isolated pojo detail level all the way through full blow integration testing.
Re: unit testing Struts2 application (with Spring and Hibernate)
On Fri, Jul 17, 2009 at 2:00 PM, Greg Lindholmgreg.lindh...@gmail.com wrote: Not to pick on anyone but this isn't really a popularity contest. Different situations have different needs and there is no reason to suggest that one solution will work best for everyone. Greg, I didn't want it to come off as a popularity thing, my point was that a lot of us might be against excessive JUnit testing because of how much of a PITA it can be within the Struts codebase. At a large shop naming something unit testing vs integration testing maybe important as it can determined who's job it is to do the work. But at a small shop, like I'm at, it makes no difference, it's all just testing and it's the developers job. So for me, whatever way is easiest, quickest and gets the job done wins. I agree that whatever is quickest and easiest wins, and I would add that you also have to try to consider the best tool for the job. It took some work at first to figure out how to tests actions with the full stack with junit but now that I have the plumbing figured out it's very easy to add tests as actions are added. With junit I can easily set the database to a know state before each test, or use mocks to simulate hard to setup edge conditions (how easy is that to do with selenium?) Plus it's easy to jun junit with code coverage so I can see code isn't being covered. And, as another already pointed out, junit is fast and convienent, 2 clicks from inside Eclipse. See, this is where I think you are missing my point. I am trying to indicate that with a tool like Selenium, you don't *need* to setup mock objects, you are dealing with a real, live deployment (hopefully on a dev-testing system). You simply deploy your app, then tell selenium to run your tests. Here's my issue with setting up mocks and trying to learn how to push actions all the way through the framework from a unit test. How do you know that we won't introduce changes that break your whole setup? I haven't read the article you have, but what I am trying to say is that if you want to test the whole flow of the framework... Why not use a tool that lets you script an interaction so that you can just replay the script? There's no need to setup mocks, etc. You are likely developing your apps by having the code in one window and a browser in another. So, why not take the spots that have been known to cause trouble, and script an interaction with it so that each time you run your tests, you can make sure that it is still operational. If you aren't familiar with Selenium, you may be completely misunderstanding why I think it's a better approach. You might install the selenium IDE and then run the selenium tests that are setup in sandbox/s2-jquery-showcase, just to see what I'm talking about. And, if you're curious, with m2eclipse and the Selenium Maven Plugin, you are likely to have it two clicks away as well. I do think it is great to see that the industry (at least those on this list) recognizes the importance of automated testing and that with Struts you have ability to test at the isolated pojo detail level all the way through full blow integration testing. -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Of course you're right Greg, it's not a contest... no right or wrong here. I am glad to hear all the views coming from everyone and commiters too. Well, my original motivation was to learn how to do this kind of tip-to-tail, all inclusive testing, with the interceptor stack involved. For example if I want to unit test an action within a secure package, that action requires the authentication interceptor to execute first, so, to do my testing I thought that the full fledged testing was necessary, to include my required interceptors. But from what I have been researching and hearing in this conversation, I believe there is a way to provide a mock object acting like my authentication interceptor and thus not need to include the interceptor stack. Also, I am not sure about testing a class which implements other struts interfaces like preparable, sessionaware, etc. Would that make a special case? Just a quick question to Wes: In your upcoming book, which is in the MEAP phase, there is an appendix titled Unit testing with JUnit and TestNG . Is there any plan to include some examples describing the different kinds of unit testing that can be done? I am looking forward to taking a look at it. On Fri, Jul 17, 2009 at 1:00 PM, Greg Lindholmgreg.lindh...@gmail.com wrote: IMO that's outside the purview of unit testing, though--by definition this describes integration testing: the testing of an action along with the framework. There's nothing *wrong* with doing that testing, I just don't think it's the same thing as unit testing: independently testing the smallest bits of functionality. JUnit can be used for that kind of testing too (and I do, sometimes), but once I'm at that point I generally figure I might as well just be doing client-focused testing and testing the output of my results. I also use Selenium, although I may switch back to using a layer I wrote on top of Watir. Dave Not to throw weight around, but it is sort of curious to me that the three struts committers who chimed in all agreed that tip-to-tail integration testing in JUnit is not worth the effort. I only bring it up because, IMO, struts 2 is one of the best-unit-tested products I've ever worked on. I think Dave, Musachy and myself are biased against tip-to-tail in JUnit because in Struts 2, we have a guideline to unit test all bugfixes and new functionality. That being so, all three of us have probably come across situations where writing the unit test is 500x harder than writing the fix :) Dave does a good job of making the point I tried to make earlier, tip-to-tail testing is better looked at as an integration test and it becomes much easier to deal with as an integration test. If you are unfamiliar with selenium, it is worth learning. One of the posters earlier mentioned that he didn't want to learn another testing framework when he already knows JUnit. Selenium is nice because it runs right in the browser (IE and Firefox) and runs though a set of VB-like instructions... Things like - open this url, look for this text, click this link and then make sure this text exists. IMO, if you want to make sure that your action renders the appropriate result, this is way better than trying to coax the framework by bootstrapping it with mocks then figuring out a way to retrieve the rendered result. As an added bonus, it is possible to get maven to launch selenium tests, so you can get full unit and integration testing out of your CI if you are willing to put forth the effort. To drive the point home further, I would add that the Dojo plugin probably would have been more stable if we had taken the selenium approach (that is being employed with the slowly moving jquery plugin). -Wes Not to pick on anyone but this isn't really a popularity contest. Different situations have different needs and there is no reason to suggest that one solution will work best for everyone. At a large shop naming something unit testing vs integration testing maybe important as it can determined who's job it is to do the work. But at a small shop, like I'm at, it makes no difference, it's all just testing and it's the developers job. So for me, whatever way is easiest, quickest and gets the job done wins. It took some work at first to figure out how to tests actions with the full stack with junit but now that I have the plumbing figured out it's very easy to add tests as actions are added. With junit I can easily set the database to a know state before each test, or use mocks to simulate hard to setup edge conditions (how easy is that to do with selenium?) Plus it's easy to jun junit with code coverage so I can see code isn't being covered. And, as another already pointed out, junit is fast and convienent, 2 clicks from inside Eclipse. I do think it is great to see that the industry (at least those on this list) recognizes
Re: unit testing Struts2 application (with Spring and Hibernate)
On Fri, Jul 17, 2009 at 2:28 PM, Dimitrios Christodoulakisdimi@gmail.com wrote: [snip] Just a quick question to Wes: In your upcoming book, which is in the MEAP phase, there is an appendix titled Unit testing with JUnit and TestNG . Is there any plan to include some examples describing the different kinds of unit testing that can be done? I am looking forward to taking a look at it. Yes, it will be very high-level, meant to demonstrate how easy testing is meant to be. IMO, a lot of the people that are still shying away from unit testing do so because (they believe) testing is difficult to setup and a hassle to maintain. There will be examples for junit, testNG, and how to inject with spring as well as using maven to automate the running of tests. I'll also discuss the various testing strategies (integration vs. unit) and basically evangelize the same position I'm arguing for on this thread :-D -Wes -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
unit testing Struts2 application (with Spring and Hibernate)
Hello, I was hoping to hear the community's views about unit testing a Struts2 application which is integrated with Spring and Hibernate. My plan is to unit test the actions with the framework's interceptors running, rather than each action class in a stand-alone isolated fashion. What approach do you usually follow? A highly regarded article: http://depressedprogrammer.wordpress.com/2007/06/18/unit-testing-struts-2-actions-spring-junit/ provides some useful hints and starting points. I would like to use Junit 4 with Ant for this. Are there any other resources, or documented steps to take as far as you know, or recommend? I found quite a few bits and pieces searching online, but would appreciate any general guidance or advice on how to begin with this. Many thanks and regards. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
I have a few thoughts on this, but I am somewhat opinionated when it comes to unit testing. Personally, I don't think it's necessary to test your actions with the interceptors. If you want to make sure that your actions fit into the struts flow of things, then unit testing is probably not the right place to do it. Personally, I would suggest that you check out selenium. In my (somewhat convoluted) opinion, tests should be thought of as one of two possible types... unit and integration tests. If you are unit testing, you should have created a small enough unit of work in your code that you can whip up a unit test that simply makes sure that your unit is doing what you intended it to do. In my opinion, unit testing isn't about creating a comprehensive set of tests that validates every possible scenario that could ever happen, it's simply about showing that through the course of development, you haven't made a change or introduced a bug through some external dependency. On the other hand, integration testing is important as well, but you shouldn't try to recreate your whole platform in JUnit, that's just creating a situation where maintaining your JUnit housekeeping code is just as much of a pain as writing your application code. If you want to integration test, then have a system set aside where you can deploy your app, then create a suite of selenium tests that will go through the user flows that you expect to work. The nice thing about this sort of setup is that you are exercising the framework, by using the framework, not by trying to recreate and maintain it. Did I mention that this is just my opinion? :) -Wes On Thu, Jul 16, 2009 at 10:43 AM, Dimitrios Christodoulakisdimi@gmail.com wrote: Hello, I was hoping to hear the community's views about unit testing a Struts2 application which is integrated with Spring and Hibernate. My plan is to unit test the actions with the framework's interceptors running, rather than each action class in a stand-alone isolated fashion. What approach do you usually follow? A highly regarded article: http://depressedprogrammer.wordpress.com/2007/06/18/unit-testing-struts-2-actions-spring-junit/ provides some useful hints and starting points. I would like to use Junit 4 with Ant for this. Are there any other resources, or documented steps to take as far as you know, or recommend? I found quite a few bits and pieces searching online, but would appreciate any general guidance or advice on how to begin with this. Many thanks and regards. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
+1 for what Wes said. Plus, I would say, the junits become so complex (when you do integration test from them), that from my experience, when they break, people don't want to fix them (because we have to admit, we are lazy). musachy On Thu, Jul 16, 2009 at 8:28 AM, Wes Wannemacherw...@wantii.com wrote: I have a few thoughts on this, but I am somewhat opinionated when it comes to unit testing. Personally, I don't think it's necessary to test your actions with the interceptors. If you want to make sure that your actions fit into the struts flow of things, then unit testing is probably not the right place to do it. Personally, I would suggest that you check out selenium. In my (somewhat convoluted) opinion, tests should be thought of as one of two possible types... unit and integration tests. If you are unit testing, you should have created a small enough unit of work in your code that you can whip up a unit test that simply makes sure that your unit is doing what you intended it to do. In my opinion, unit testing isn't about creating a comprehensive set of tests that validates every possible scenario that could ever happen, it's simply about showing that through the course of development, you haven't made a change or introduced a bug through some external dependency. On the other hand, integration testing is important as well, but you shouldn't try to recreate your whole platform in JUnit, that's just creating a situation where maintaining your JUnit housekeeping code is just as much of a pain as writing your application code. If you want to integration test, then have a system set aside where you can deploy your app, then create a suite of selenium tests that will go through the user flows that you expect to work. The nice thing about this sort of setup is that you are exercising the framework, by using the framework, not by trying to recreate and maintain it. Did I mention that this is just my opinion? :) -Wes On Thu, Jul 16, 2009 at 10:43 AM, Dimitrios Christodoulakisdimi@gmail.com wrote: Hello, I was hoping to hear the community's views about unit testing a Struts2 application which is integrated with Spring and Hibernate. My plan is to unit test the actions with the framework's interceptors running, rather than each action class in a stand-alone isolated fashion. What approach do you usually follow? A highly regarded article: http://depressedprogrammer.wordpress.com/2007/06/18/unit-testing-struts-2-actions-spring-junit/ provides some useful hints and starting points. I would like to use Junit 4 with Ant for this. Are there any other resources, or documented steps to take as far as you know, or recommend? I found quite a few bits and pieces searching online, but would appreciate any general guidance or advice on how to begin with this. Many thanks and regards. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Well everyone has an opinion so here mine: I want to unit test my Struts actions in the full Struts context which includes the interceptor stack and validation. This way I know my actions and results are configured correctly since I test them. I also know my declarative validations are working correctly. I use junit and I really don't want or have time to have to learn another test tool for integration testing. So to do this type of testing I wrote a StrutsTestContext class to run my actions. For full info see: http://glindholm.wordpress.com/2008/06/30/unit-testing-struts-2-actions/ I don't use Spring so this class would need to be tweaked for Spring but you are welcome to use this as a starting point. This gives me a lot of flexibility for testing, sometimes I test against an actual database (with hibernate) and sometimes I mock the services that the actions use. On Thu, Jul 16, 2009 at 10:43 AM, Dimitrios Christodoulakis dimi@gmail.com wrote: Hello, I was hoping to hear the community's views about unit testing a Struts2 application which is integrated with Spring and Hibernate. My plan is to unit test the actions with the framework's interceptors running, rather than each action class in a stand-alone isolated fashion. What approach do you usually follow? A highly regarded article: http://depressedprogrammer.wordpress.com/2007/06/18/unit-testing-struts-2-actions-spring-junit/ provides some useful hints and starting points. I would like to use Junit 4 with Ant for this. Are there any other resources, or documented steps to take as far as you know, or recommend? I found quite a few bits and pieces searching online, but would appreciate any general guidance or advice on how to begin with this. Many thanks and regards. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Thanks everyone for their opinions. I was indeed hoping to hear both sides of this matter, with both bringing valid arguments and make good points. I was wondering with popular frameworks like struts, spring and hibernate integrated together and the increasing adoption of test driven, and agile development, there should be at least a couple of comprehensive, and well documented strategies on how to perform such kind of unit testing with the whole working stack included in the unit tests. I am somewhat curious in trying to do this and making it work, so if anyone is aware of any other resources, or strategies in addition to Greg's article, where Spring is involved, I'd be very interested in taking a look at them. Or, if someone has done such Struts testing before and wouldn't mind sharing some high-level advice, or hints toward a good starting point, that would be very helpful and I am sure others can find this information of value too. Again, thank you for your input. On Thu, Jul 16, 2009 at 12:19 PM, Greg Lindholmgreg.lindh...@gmail.com wrote: Well everyone has an opinion so here mine: I want to unit test my Struts actions in the full Struts context which includes the interceptor stack and validation. This way I know my actions and results are configured correctly since I test them. I also know my declarative validations are working correctly. I use junit and I really don't want or have time to have to learn another test tool for integration testing. So to do this type of testing I wrote a StrutsTestContext class to run my actions. For full info see: http://glindholm.wordpress.com/2008/06/30/unit-testing-struts-2-actions/ I don't use Spring so this class would need to be tweaked for Spring but you are welcome to use this as a starting point. This gives me a lot of flexibility for testing, sometimes I test against an actual database (with hibernate) and sometimes I mock the services that the actions use. On Thu, Jul 16, 2009 at 10:43 AM, Dimitrios Christodoulakis dimi@gmail.com wrote: Hello, I was hoping to hear the community's views about unit testing a Struts2 application which is integrated with Spring and Hibernate. My plan is to unit test the actions with the framework's interceptors running, rather than each action class in a stand-alone isolated fashion. What approach do you usually follow? A highly regarded article: http://depressedprogrammer.wordpress.com/2007/06/18/unit-testing-struts-2-actions-spring-junit/ provides some useful hints and starting points. I would like to use Junit 4 with Ant for this. Are there any other resources, or documented steps to take as far as you know, or recommend? I found quite a few bits and pieces searching online, but would appreciate any general guidance or advice on how to begin with this. Many thanks and regards. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
On Today at 1:19pm, GL=Greg Lindholm greg.lindh...@gmail.com wrote: GL Well everyone has an opinion so here mine: GL GL I want to unit test my Struts actions in the full Struts context which GL includes the interceptor stack and validation. This way I know my GL actions and results are configured correctly since I test them. I also GL know my declarative validations are working correctly. I use junit and GL I really don't want or have time to have to learn another test tool GL for integration testing. GL Hi, +1. I'm biased in my opinion though. I helped write part of the code that's being quoted on: http://depressedprogrammer.wordpress.com/2007/06/18/unit-testing-struts-2-actions-spring-junit/ We like to test against the complete struts context include the relevant interceptor stack. This gives us the ability to test for all kinds of combinations of compelte and partially incomplete input. We like to test with mock database layer (for speed purposes). E.g., when providing incomplete input, I can test for: assertEquals(INPUT, proxy.execute()); assertEquals(4 field errors, 4, action.getFieldErrors().size()); In addition, we also like to test out the rendered result, all while running the ActionTest. It helps catch fat-finger mistakes. E.g, we can write code like to check that our freemarker template got rendered properly: assertTrue(Content contains first record, content.contains({'institutionType.type': 'CEC'})); assertTrue(Content contains last record, content.contains({'institutionType.type': 'COL'})); assertEquals(Number of records in list should be 4, 4, StringUtils.countMatches(content, 'institutionType.type':)); GL GL So to do this type of testing I wrote a StrutsTestContext class to run my GL actions. GL For full info see: GL http://glindholm.wordpress.com/2008/06/30/unit-testing-struts-2-actions/ GL I glanced briefly at the provided code on Greg's and it looks similar in principle to the depressedprogrammer (arsenalist) code. Good work, Greg. GL GL I don't use Spring so this class would need to be tweaked for Spring but you GL are welcome to use this as a starting point. GL GL This gives me a lot of flexibility for testing, sometimes I test GL against an actual database (with hibernate) and sometimes I mock the GL services that the actions use. GL Later, -- Haroon Rafique haroon.rafi...@utoronto.ca - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
If it's integration testing you want to do, I've had success embedding Jetty and doing full in-container integration testing. Embedding Jetty is really easy, and it's pretty fast too. Although not Struts 2 specific, take a look at this article: http://today.java.net/pub/a/today/2007/04/12/embedded-integration-testing-of-web-applications.html Nils-H On Thu, Jul 16, 2009 at 8:27 PM, Dimitrios Christodoulakisdimi@gmail.com wrote: Thanks everyone for their opinions. I was indeed hoping to hear both sides of this matter, with both bringing valid arguments and make good points. I was wondering with popular frameworks like struts, spring and hibernate integrated together and the increasing adoption of test driven, and agile development, there should be at least a couple of comprehensive, and well documented strategies on how to perform such kind of unit testing with the whole working stack included in the unit tests. I am somewhat curious in trying to do this and making it work, so if anyone is aware of any other resources, or strategies in addition to Greg's article, where Spring is involved, I'd be very interested in taking a look at them. Or, if someone has done such Struts testing before and wouldn't mind sharing some high-level advice, or hints toward a good starting point, that would be very helpful and I am sure others can find this information of value too. Again, thank you for your input. On Thu, Jul 16, 2009 at 12:19 PM, Greg Lindholmgreg.lindh...@gmail.com wrote: Well everyone has an opinion so here mine: I want to unit test my Struts actions in the full Struts context which includes the interceptor stack and validation. This way I know my actions and results are configured correctly since I test them. I also know my declarative validations are working correctly. I use junit and I really don't want or have time to have to learn another test tool for integration testing. So to do this type of testing I wrote a StrutsTestContext class to run my actions. For full info see: http://glindholm.wordpress.com/2008/06/30/unit-testing-struts-2-actions/ I don't use Spring so this class would need to be tweaked for Spring but you are welcome to use this as a starting point. This gives me a lot of flexibility for testing, sometimes I test against an actual database (with hibernate) and sometimes I mock the services that the actions use. On Thu, Jul 16, 2009 at 10:43 AM, Dimitrios Christodoulakis dimi@gmail.com wrote: Hello, I was hoping to hear the community's views about unit testing a Struts2 application which is integrated with Spring and Hibernate. My plan is to unit test the actions with the framework's interceptors running, rather than each action class in a stand-alone isolated fashion. What approach do you usually follow? A highly regarded article: http://depressedprogrammer.wordpress.com/2007/06/18/unit-testing-struts-2-actions-spring-junit/ provides some useful hints and starting points. I would like to use Junit 4 with Ant for this. Are there any other resources, or documented steps to take as far as you know, or recommend? I found quite a few bits and pieces searching online, but would appreciate any general guidance or advice on how to begin with this. Many thanks and regards. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Haroon Rafique wrote: We like to test against the complete struts context include the relevant interceptor stack. This gives us the ability to test for all kinds of combinations of compelte and partially incomplete input. IMO that's outside the purview of unit testing, though--by definition this describes integration testing: the testing of an action along with the framework. There's nothing *wrong* with doing that testing, I just don't think it's the same thing as unit testing: independently testing the smallest bits of functionality. JUnit can be used for that kind of testing too (and I do, sometimes), but once I'm at that point I generally figure I might as well just be doing client-focused testing and testing the output of my results. I also use Selenium, although I may switch back to using a layer I wrote on top of Watir. Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
On Thursday 16 July 2009 07:14:30 pm Dave Newton wrote: IMO that's outside the purview of unit testing, though--by definition this describes integration testing: the testing of an action along with the framework. There's nothing *wrong* with doing that testing, I just don't think it's the same thing as unit testing: independently testing the smallest bits of functionality. JUnit can be used for that kind of testing too (and I do, sometimes), but once I'm at that point I generally figure I might as well just be doing client-focused testing and testing the output of my results. I also use Selenium, although I may switch back to using a layer I wrote on top of Watir. Dave Not to throw weight around, but it is sort of curious to me that the three struts committers who chimed in all agreed that tip-to-tail integration testing in JUnit is not worth the effort. I only bring it up because, IMO, struts 2 is one of the best-unit-tested products I've ever worked on. I think Dave, Musachy and myself are biased against tip-to-tail in JUnit because in Struts 2, we have a guideline to unit test all bugfixes and new functionality. That being so, all three of us have probably come across situations where writing the unit test is 500x harder than writing the fix :) Dave does a good job of making the point I tried to make earlier, tip-to-tail testing is better looked at as an integration test and it becomes much easier to deal with as an integration test. If you are unfamiliar with selenium, it is worth learning. One of the posters earlier mentioned that he didn't want to learn another testing framework when he already knows JUnit. Selenium is nice because it runs right in the browser (IE and Firefox) and runs though a set of VB-like instructions... Things like - open this url, look for this text, click this link and then make sure this text exists. IMO, if you want to make sure that your action renders the appropriate result, this is way better than trying to coax the framework by bootstrapping it with mocks then figuring out a way to retrieve the rendered result. As an added bonus, it is possible to get maven to launch selenium tests, so you can get full unit and integration testing out of your CI if you are willing to put forth the effort. To drive the point home further, I would add that the Dojo plugin probably would have been more stable if we had taken the selenium approach (that is being employed with the slowly moving jquery plugin). -Wes -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org