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<greg.lindh...@gmail.com> wrote: >> >> > > >> > > IMO that's outside the purview of unit testing, though--by definition >> > > this describes integration testing: the testing of an action along with >> > > the framework. >> > > >> > > There's nothing *wrong* with doing that testing, I just don't think >> it's >> > > the same thing as unit testing: independently testing the smallest bits >> > > of functionality. >> > > >> > > JUnit can be used for that kind of testing too (and I do, sometimes), >> > > but once I'm at that point I generally figure I might as well just be >> > > doing client-focused testing and testing the output of my results. I >> > > also use Selenium, although I may switch back to using a layer I wrote >> > > on top of Watir. >> > > >> > > Dave >> > > >> > >> > Not to throw weight around, but it is sort of curious to me that the >> three >> > struts committers who chimed in all agreed that tip-to-tail integration >> > testing in JUnit is not worth the effort. I only bring it up because, >> IMO, >> > struts 2 is one of the best-unit-tested products I've ever worked on. I >> think >> > Dave, Musachy and myself are biased against tip-to-tail in JUnit because >> in >> > Struts 2, we have a guideline to unit test all bugfixes and new >> functionality. >> > That being so, all three of us have probably come across situations where >> > writing the unit test is 500x harder than writing the fix :) >> > >> > Dave does a good job of making the point I tried to make earlier, >> tip-to-tail >> > testing is better looked at as an integration test and it becomes much >> easier >> > to deal with as an integration test. If you are unfamiliar with selenium, >> it >> > is worth learning. One of the posters earlier mentioned that he didn't >> want to >> > learn another testing framework when he already knows JUnit. Selenium is >> nice >> > because it runs right in the browser (IE and Firefox) and runs though a >> set of >> > VB-like instructions... Things like - open this url, look for this text, >> click >> > this link and then make sure this text exists. IMO, if you want to make >> sure >> > that your action renders the appropriate result, this is way better than >> > trying to coax the framework by bootstrapping it with mocks then figuring >> out a >> > way to retrieve the rendered result. As an added bonus, it is possible to >> get >> > maven to launch selenium tests, so you can get full unit and integration >> > testing out of your CI if you are willing to put forth the effort. >> > >> > To drive the point home further, I would add that the Dojo plugin >> probably >> > would have been more stable if we had taken the selenium approach (that >> is >> > being employed with the slowly moving jquery plugin). >> > >> > -Wes >> > >> > > Not to pick on anyone but this isn't really a popularity contest. Different > situations have different needs and there is no reason to suggest that one > solution will work best for everyone. > > At a large shop naming something "unit testing" vs "integration testing" > maybe important as it can determined who's job it is to do the work. But at > a small shop, like I'm at, it makes no difference, it's all just testing and > it's the developers job. So for me, whatever way is easiest, quickest and > gets the job done wins. > > It took some work at first to figure out how to tests actions with the full > stack with junit but now that I have the plumbing figured out it's very easy > to add tests as actions are added. With junit I can easily set the database > to a know state before each test, or use mocks to simulate hard to setup > edge conditions (how easy is that to do with selenium?) Plus it's easy to > jun junit with code coverage so I can see code isn't being covered. And, as > another already pointed out, junit is fast and convienent, 2 clicks from > inside Eclipse. > > I do think it is great to see that the industry (at least those on this > list) recognizes 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
