On Fri, Jul 17, 2009 at 2:00 PM, Greg Lindholm<greg.lindh...@gmail.com> wrote: > > Not to pick on anyone but this isn't really a popularity contest. Different > situations have different needs and there is no reason to suggest that one > solution will work best for everyone.
Greg, I didn't want it to come off as a popularity thing, my point was that a lot of us might be against excessive JUnit testing because of how much of a PITA it can be within the Struts codebase. > > At a large shop naming something "unit testing" vs "integration testing" > maybe important as it can determined who's job it is to do the work. But at > a small shop, like I'm at, it makes no difference, it's all just testing and > it's the developers job. So for me, whatever way is easiest, quickest and > gets the job done wins. I agree that whatever is quickest and easiest wins, and I would add that you also have to try to consider the best tool for the job. > > It took some work at first to figure out how to tests actions with the full > stack with junit but now that I have the plumbing figured out it's very easy > to add tests as actions are added. With junit I can easily set the database > to a know state before each test, or use mocks to simulate hard to setup > edge conditions (how easy is that to do with selenium?) Plus it's easy to > jun junit with code coverage so I can see code isn't being covered. And, as > another already pointed out, junit is fast and convienent, 2 clicks from > inside Eclipse. See, this is where I think you are missing my point. I am trying to indicate that with a tool like Selenium, you don't *need* to setup mock objects, you are dealing with a real, live deployment (hopefully on a dev-testing system). You simply deploy your app, then tell selenium to run your tests. Here's my issue with setting up mocks and trying to learn how to push actions all the way through the framework from a unit test. How do you know that we won't introduce changes that break your whole setup? I haven't read the article you have, but what I am trying to say is that if you want to test the whole flow of the framework... Why not use a tool that lets you script an interaction so that you can just replay the script? There's no need to setup mocks, etc. You are likely developing your apps by having the code in one window and a browser in another. So, why not take the spots that have been known to cause trouble, and script an interaction with it so that each time you run your tests, you can make sure that it is still operational. If you aren't familiar with Selenium, you may be completely misunderstanding why I think it's a better approach. You might install the selenium IDE and then run the selenium tests that are setup in sandbox/s2-jquery-showcase, just to see what I'm talking about. And, if you're curious, with m2eclipse and the Selenium Maven Plugin, you are likely to have it two clicks away as well. > > I do think it is great to see that the industry (at least those on this > list) recognizes the importance of automated testing and that with Struts > you have ability to test at the isolated pojo detail level all the way > through full blow integration testing. > -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
