Thanks for this news! I will give it a try. On Fri, Aug 7, 2009 at 1:56 PM, Musachy Barroso<musa...@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 > Christodoulakis<dimi....@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 >> Rafique<haroon.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 >> >> > > > > -- > "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 > >
--------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
