I plan to unit test the interceptor on its own. I am more interested in testing its logic, not necessarily within the framework.
First step would be to mock an ActionInvocation object which is what is passed to the Interceptor's intercept method. The action invocation would need a mock action, and a mock session which will be holding the user credentials. In order to have a session I would need to first have an invocation object to get the session from: actionInvocation.getInvocationContext().getSession() On Fri, Jul 24, 2009 at 10:52 AM, Musachy Barroso<musa...@gmail.com> wrote: > You don't need to create mock objects for the framework, you onlt need > to mock the objects passed to the interceptor and invoke the > interceptor directly, unless you really want to test the interceptor > running inside struts (there is a long thread about that so i wont get > into it) > > musachy > > On Fri, Jul 24, 2009 at 6:31 AM, Dimitrios > Christodoulakis<dimi....@gmail.com> wrote: >> I tried to logically trace the flow within the framework and wanted to >> check if my thoughts are correct here, while at the same time asking a >> few more questions: >> >> As a start I take DefaultActionProxyFactory. DefaultActionProxyFactory >> instantiates DefaultActionProxy, but also gives us >> DefaultActionInvocation via its createActionProxy methods, using the >> "new" operator. >> >> The DefaultActionProxy constructor takes ActionInvocation as parameter >> and sets the ActionInvocation interface field by means of a >> DefaultActionInvocation implementation. >> >> Next, DefaultActionInvocation takes extraContext and a boolean as >> constructor params. It also has a reference to the ActionProxy which I >> believe sets via its init method? >> >> DefaultActionInvocation also creates the actions with its >> createAction(Map<String, Object> contextMap) method, letting an >> objectFactory take care of the actual creation with information taken >> from the ActionProxy (like action name, name space, config, etc). >> >> Then DefaultActionInvocation also invokes the action by calling >> invokeAction(action, actionConfig). >> >> This is more to help me understand the basic workflow at a higher >> level at first. Are my above statements correct? >> >> One thing that I find confusing (at this time) is the use of so many >> "contexts": extraContext, actionContext, invocationContext, etc. What >> is the primary use of the context? Is it similar to the configuration >> object? >> >> I still have as a short term objective to unit test my >> intercept(actionInvocation) method of my custom Interceptor, but is it >> true to assume that to prepare for the test I'd probably need to >> create a lot of dependencies manually? i.e. Create mock objects all >> the way deep to DefaultActionProxyFactory? >> >> Many thanks again for your help. >> >> >> >> >> On Thu, Jul 23, 2009 at 5:37 PM, Dave Newton<newton.d...@yahoo.com> wrote: >>> Dimitrios Christodoulakis wrote: >>>> >>>> By the way I noticed that when I downloaded the s2 source code, it >>>> didn't come with the opensymphony packages... Does the xwork source >>>> has to be downloaded separately? >>> >>> Yes. >>> >>> 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 >> >> > > > > -- > "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
