>
> 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
