Hi all, [the standard disclaimer ... ;-) ] migrating from one version of struts to another is not a trouble for selenium or such a tool, actually it even helps You to be sure that the migration didn't break anything. But You will hit the same scale of problems when You will change layout - all selenium tests are dead, of course one may argue that he is able to write selenium tests that way that it will stay alive but that will be extra effort to cope with that.
Every solution have it's own set of troubles involved. The is no better way, i think. We can point out pros and cons of solutions we use, so that others could make theirs decisions based on our experiences. Best greetings, Paweł Wielgus. 2009/7/19 <musom...@aol.com>: > > [The standard?diclaimer that it is not a popularity contest and nothing that > does the job for you is wrong.] > Would you not agree that if you are going to mock up the framework the > simulation of S2 of highest fidelity is S2 itself. > IMHO?you are digging a swimming pool by the ocean to test your yatch. > I am not familiar with Selenium but anything you can do with JUnit you can do > in JWebUnit since it is just > JUnit with more libraries. > > I took your route or instantiating parts of S2 in standard JUnit tests and > run into trouble when I moved > from 2,0,x to 2,1,x due to changes in the framework. It is a bummer when you > switch versions and find > the tests are dead. > Chris > > > > -----Original Message----- > From: Greg Lindholm <greg.lindh...@gmail.com> > To: Struts Users Mailing List <user@struts.apache.org> > Sent: Sat, Jul 18, 2009 3:00 am > Subject: Re: unit testing Struts2 application (with Spring and Hibernate) > > > >> >> > > >> > > IMO that's outside the purview of unit testing, though--by definition >> > > this describes integration testing: the testing of an action along with >> > > the framework. >> > > >> > > There's nothing *wrong* with doing that testing, I just don't think >> it's >> > > the same thing as unit testing: independently testing the smallest bits >> > > of functionality. >> > > >> > > JUnit can be used for that kind of testing too (and I do, sometimes), >> > > but once I'm at that point I generally figure I might as well just be >> > > doing client-focused testing and testing the output of my results. I >> > > also use Selenium, although I may switch back to using a layer I wrote >> > > on top of Watir. >> > > >> > > Dave >> > > >> > >> > Not to throw weight around, but it is sort of curious to me that the >> three >> > struts committers who chimed in all agreed that tip-to-tail integration >> > testing in JUnit is not worth the effort. I only bring it up because, >> IMO, >> > struts 2 is one of the best-unit-tested products I've ever worked on. I >> think >> > Dave, Musachy and myself are biased against tip-to-tail in JUnit because >> in >> > Struts 2, we have a guideline to unit test all bugfixes and new >> functionality. >> > That being so, all three of us have probably come across situations where >> > writing the unit test is 500x harder than writing the fix :) >> > >> > Dave does a good job of making the point I tried to make earlier, >> tip-to-tail >> > testing is better looked at as an integration test and it becomes much >> easier >> > to deal with as an integration test. If you are unfamiliar with selenium, >> it >> > is worth learning. One of the posters earlier mentioned that he didn't >> want to >> > learn another testing framework when he already knows JUnit. Selenium is >> nice >> > because it runs right in the browser (IE and Firefox) and runs though a >> set of >> > VB-like instructions... Things like - open this url, look for this text, >> click >> > this link and then make sure this text exists. IMO, if you want to make >> sure >> > th > at your action renders the appropriate result, this is way better than >> > trying to coax the framework by bootstrapping it with mocks then figuring >> out a >> > way to retrieve the rendered result. As an added bonus, it is possible to >> get >> > maven to launch selenium tests, so you can get full unit and integration >> > testing out of your CI if you are willing to put forth the effort. >> > >> > To drive the point home further, I would add that the Dojo plugin >> probably >> > would have been more stable if we had taken the selenium approach (that >> is >> > being employed with the slowly moving jquery plugin). >> > >> > -Wes >> > >> > > Not to pick on anyone but this isn't really a popularity contest. Different > situations have different needs and there is no reason to suggest that one > solution will work best for everyone. > > At a large shop naming something "unit testing" vs "integration testing" > maybe important as it can determined who's job it is to do the work. But at > a small shop, like I'm at, it makes no difference, it's all just testing and > it's the developers job. So for me, whatever way is easiest, quickest and > gets the job done wins. > > It took some work at first to figure out how to tests actions with the full > stack with junit but now that I have the plumbing figured out it's very easy > to add tests as actions are added. With junit I can easily set the database > to a know state before 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-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
