You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Dimitrios Christodoulakis <di...@gmail.com> on 2009/07/16 16:43:06 UTC
unit testing Struts2 application (with Spring and Hibernate)
Hello,
I was hoping to hear the community's views about unit testing a
Struts2 application which is integrated with Spring and Hibernate. My
plan is to unit test the actions with the framework's interceptors
running, rather than each action class in a stand-alone isolated
fashion.
What approach do you usually follow? A highly regarded article:
http://depressedprogrammer.wordpress.com/2007/06/18/unit-testing-struts-2-actions-spring-junit/
provides some useful hints and starting points.
I would like to use Junit 4 with Ant for this. Are there any other
resources, or documented steps to take as far as you know, or
recommend?
I found quite a few bits and pieces searching online, but would
appreciate any general guidance or advice on how to begin with this.
Many thanks and regards.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Musachy Barroso <mu...@gmail.com>.
+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 Wannemacher<we...@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
> Christodoulakis<di...@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-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Wes Wannemacher <we...@wantii.com>.
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
Christodoulakis<di...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Wes Wannemacher <we...@wantii.com>.
On Fri, Jul 17, 2009 at 2:28 PM, Dimitrios
Christodoulakis<di...@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Dimitrios Christodoulakis <di...@gmail.com>.
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 Lindholm<gr...@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 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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Wes Wannemacher <we...@wantii.com>.
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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Dimitrios Christodoulakis <di...@gmail.com>.
Thanks for this news! I will give it a try.
On Fri, Aug 7, 2009 at 1:56 PM, Musachy Barroso<mu...@gmail.com> wrote:
> I have updated the JUnit plugin, to provide support for this kind of
> testing(also for spring testing), see the documentation here:
>
> http://cwiki.apache.org/confluence/display/WW/Testing+Actions
>
> See the 2 classes here:
>
> http://svn.apache.org/viewvc/struts/struts2/trunk/plugins/junit/src/main/java/org/apache/struts2/
>
> feedback is welcome, before 2.1.8 is released, using this classes you
> can test your action output like:
>
> public void testExecuteAction() throws ServletException,
> UnsupportedEncodingException {
> String output = executeAction("/test/testAction.action");
> assertEquals("Hello", output);
> }
>
> for something like this to work you will have to use FreeMarker or
> velocity for the results, or the experimental JSP plugin:
>
> http://cwiki.apache.org/S2PLUGINS/embedded-jsp-plugin.html
>
> musachy
>
> On Tue, Jul 21, 2009 at 2:26 PM, Dimitrios
> Christodoulakis<di...@gmail.com> wrote:
>>>
>>> In your code below, where you say // and then execute proxy again, are you
>>> missing some stepls where you need to supply some parameters to the
>>> action?
>>>
>> Yes, that wasn't actual code, just the steps I was considering.
>>
>> -In any case it's good to know the limitations of the example. You are
>> right, sometimes I need to test a broader unit of work, which can
>> include a couple of actions, rather than just one. So, in that sense,
>> I could be stepping into the functional testing area.
>>
>> I appreciate all the helpful information. I've already learned a lot,
>> by the example code, and the discussions on this thread!
>>
>>
>> On Tue, Jul 21, 2009 at 3:31 PM, Haroon
>> Rafique<ha...@utoronto.ca> wrote:
>>> On Today at 2:02pm, DC=>Dimitrios Christodoulakis <di...@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
>>> <ha...@utoronto.ca>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Dimitrios Christodoulakis <di...@gmail.com>.
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 Gainty<mg...@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.chr@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
>> Rafique<ha...@utoronto.ca> wrote:
>> > On Today at 4:32pm, DC=>Dimitrios Christodoulakis <di...@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(Map<String, String>
>> > parameters) {
>> > proxy.getInvocation().getInvocationContext().
>> > setParameters(parameters);
>> > }
>> >
>> > Then inside my Action Test class, I can issue:
>> > proxy.setActionParameters(...);
>> > before:
>> > proxy.execute();
>> >
>> > Cheers,
>> > --
>> > Haroon Rafique
>> > <ha...@utoronto.ca>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: user-help@struts.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@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_072009&cat=sports
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Musachy Barroso <mu...@gmail.com>.
I have updated the JUnit plugin, to provide support for this kind of
testing(also for spring testing), see the documentation here:
http://cwiki.apache.org/confluence/display/WW/Testing+Actions
See the 2 classes here:
http://svn.apache.org/viewvc/struts/struts2/trunk/plugins/junit/src/main/java/org/apache/struts2/
feedback is welcome, before 2.1.8 is released, using this classes you
can test your action output like:
public void testExecuteAction() throws ServletException,
UnsupportedEncodingException {
String output = executeAction("/test/testAction.action");
assertEquals("Hello", output);
}
for something like this to work you will have to use FreeMarker or
velocity for the results, or the experimental JSP plugin:
http://cwiki.apache.org/S2PLUGINS/embedded-jsp-plugin.html
musachy
On Tue, Jul 21, 2009 at 2:26 PM, Dimitrios
Christodoulakis<di...@gmail.com> wrote:
>>
>> In your code below, where you say // and then execute proxy again, are you
>> missing some stepls where you need to supply some parameters to the
>> action?
>>
> Yes, that wasn't actual code, just the steps I was considering.
>
> -In any case it's good to know the limitations of the example. You are
> right, sometimes I need to test a broader unit of work, which can
> include a couple of actions, rather than just one. So, in that sense,
> I could be stepping into the functional testing area.
>
> I appreciate all the helpful information. I've already learned a lot,
> by the example code, and the discussions on this thread!
>
>
> On Tue, Jul 21, 2009 at 3:31 PM, Haroon
> Rafique<ha...@utoronto.ca> wrote:
>> On Today at 2:02pm, DC=>Dimitrios Christodoulakis <di...@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
>> <ha...@utoronto.ca>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Dimitrios Christodoulakis <di...@gmail.com>.
>
> In your code below, where you say // and then execute proxy again, are you
> missing some stepls where you need to supply some parameters to the
> action?
>
Yes, that wasn't actual code, just the steps I was considering.
-In any case it's good to know the limitations of the example. You are
right, sometimes I need to test a broader unit of work, which can
include a couple of actions, rather than just one. So, in that sense,
I could be stepping into the functional testing area.
I appreciate all the helpful information. I've already learned a lot,
by the example code, and the discussions on this thread!
On Tue, Jul 21, 2009 at 3:31 PM, Haroon
Rafique<ha...@utoronto.ca> wrote:
> On Today at 2:02pm, DC=>Dimitrios Christodoulakis <di...@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
> <ha...@utoronto.ca>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Haroon Rafique <ha...@utoronto.ca>.
On Today at 2:02pm, DC=>Dimitrios Christodoulakis <di...@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
<ha...@utoronto.ca>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Dimitrios Christodoulakis <di...@gmail.com>.
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
Rafique<ha...@utoronto.ca> wrote:
> On Today at 4:32pm, DC=>Dimitrios Christodoulakis <di...@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(Map<String, String>
> parameters) {
> proxy.getInvocation().getInvocationContext().
> setParameters(parameters);
> }
>
> Then inside my Action Test class, I can issue:
> proxy.setActionParameters(...);
> before:
> proxy.execute();
>
> Cheers,
> --
> Haroon Rafique
> <ha...@utoronto.ca>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: unit testing Struts2 application (with Spring and Hibernate)
Posted by Martin Gainty <mg...@hotmail.com>.
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.chr@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
> Rafique<ha...@utoronto.ca> wrote:
> > On Today at 4:32pm, DC=>Dimitrios Christodoulakis <di...@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(Map<String, String>
> > parameters) {
> > proxy.getInvocation().getInvocationContext().
> > setParameters(parameters);
> > }
> >
> > Then inside my Action Test class, I can issue:
> > proxy.setActionParameters(...);
> > before:
> > proxy.execute();
> >
> > Cheers,
> > --
> > Haroon Rafique
> > <ha...@utoronto.ca>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@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_072009&cat=sports
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Dimitrios Christodoulakis <di...@gmail.com>.
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
Rafique<ha...@utoronto.ca> wrote:
> On Today at 4:32pm, DC=>Dimitrios Christodoulakis <di...@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(Map<String, String>
> parameters) {
> proxy.getInvocation().getInvocationContext().
> setParameters(parameters);
> }
>
> Then inside my Action Test class, I can issue:
> proxy.setActionParameters(...);
> before:
> proxy.execute();
>
> Cheers,
> --
> Haroon Rafique
> <ha...@utoronto.ca>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Haroon Rafique <ha...@utoronto.ca>.
On Today at 4:32pm, DC=>Dimitrios Christodoulakis <di...@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(Map<String, String>
parameters) {
proxy.getInvocation().getInvocationContext().
setParameters(parameters);
}
Then inside my Action Test class, I can issue:
proxy.setActionParameters(...);
before:
proxy.execute();
Cheers,
--
Haroon Rafique
<ha...@utoronto.ca>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Dimitrios Christodoulakis <di...@gmail.com>.
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
Rafique<ha...@utoronto.ca> wrote:
> On Yesterday at 9:16pm, DC=>Dimitrios Christodoulakis <di...@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
> <ha...@utoronto.ca>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Haroon Rafique <ha...@utoronto.ca>.
On Yesterday at 9:16pm, DC=>Dimitrios Christodoulakis <di...@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
<ha...@utoronto.ca>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Dimitrios Christodoulakis <di...@gmail.com>.
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 Newton<ne...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Dave Newton <ne...@yahoo.com>.
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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Paweł Wielgus <po...@gmail.com>.
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 <ne...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Dave Newton <ne...@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Paweł Wielgus <po...@gmail.com>.
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 <mu...@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 <gr...@gmail.com>
> To: Struts Users Mailing List <us...@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.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by mu...@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 <gr...@gmail.com>
To: Struts Users Mailing List <us...@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)
Posted by Wes Wannemacher <we...@wantii.com>.
On Fri, Jul 17, 2009 at 2:00 PM, Greg Lindholm<gr...@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Greg Lindholm <gr...@gmail.com>.
>
> > >
> > > 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)
Posted by Andy <an...@hotmail.com>.
Couldn't agree more.
> From: wesw@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@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)
Posted by Paweł Wielgus <po...@gmail.com>.
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 <we...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by mu...@aol.com.
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 <we...@wantii.com>
To: Struts Users Mailing List <us...@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Wes Wannemacher <we...@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Dave Newton <ne...@yahoo.com>.
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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Haroon Rafique <ha...@utoronto.ca>.
On Today at 1:19pm, GL=>Greg Lindholm <gr...@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
<ha...@utoronto.ca>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Nils-Helge Garli Hegvik <ni...@gmail.com>.
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
Christodoulakis<di...@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 Lindholm<gr...@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.chr@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-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Dimitrios Christodoulakis <di...@gmail.com>.
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 Lindholm<gr...@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.chr@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-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: unit testing Struts2 application (with Spring and Hibernate)
Posted by Greg Lindholm <gr...@gmail.com>.
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.chr@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>