Re: unit testing Struts2 application (with Spring and Hibernate)

[Musachy Barroso]

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)

[Dimitrios Christodoulakis]

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)

[Dimitrios Christodoulakis]

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)

[Haroon Rafique]

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)

[Dimitrios Christodoulakis]

 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)

[Haroon Rafique]

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)

[Dimitrios Christodoulakis]

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)

[Haroon Rafique]

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)

[Dimitrios Christodoulakis]

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)

[Martin Gainty]

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)

[Dimitrios Christodoulakis]

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)

[musomesa]

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

[Paweł Wielgus]

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)

[Dave Newton]

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)

[Paweł Wielgus]

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)

[Dave Newton]

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)

[Dimitrios Christodoulakis]

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)

[Wes Wannemacher]

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)

[Paweł Wielgus]

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)

[musomesa]

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)

[Andy]

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)

[Greg Lindholm]

  
   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)

[Wes Wannemacher]

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)

[Dimitrios Christodoulakis]

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)

[Wes Wannemacher]

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

Re: unit testing Struts2 application (with Spring and Hibernate)

[Wes Wannemacher]

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)

[Musachy Barroso]

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

[Greg Lindholm]

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)

[Dimitrios Christodoulakis]

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)

[Haroon Rafique]

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)

[Nils-Helge Garli Hegvik]

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)

[Dave Newton]

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)

[Wes Wannemacher]

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