I'm almost at the point where I'm ready to give up on integration tests, particular of the web interface layer. (I will still do integration testing of the db layer, because hibernate is just too complicated with respect to cascading and transients to avoid it.) I blogged a little about this here:
http://www.42lines.net/blog/clint/do-we-need-integration-testing which was sort of inspired by reading this by J.B. Rainsberger, which really resonated for me: http://www.jbrains.ca/permalink/239 a while back. When we do wicket integration tests, we do them with jdave (which I highly recommend) but on new work I'm considering officially _not_ doing them and focusing that energy and time on better unit testing with mocks. With all things, it depends on the project, and I won't preach _against_ integration testing necessarily. I'll just say that I burn too much time running them, fixing them when the UI changes, and they cover only a tiny percentage of possible UI scenarios, particularly when AJAX comes into play, so I doubt whether they're cost effective. And FWIW, this has been true for me under Wicket, JSF, Struts, and plain jsp, for 8 years. So either I'm really poor at it, or I'm really slow at recognising a pattern :) -Clint On Tue, May 12, 2009 at 7:36 PM, Kent Larsson <kent.lars...@gmail.com> wrote: > > Hi, > > For my last project (not using Wicket) I used HtmlUnit to simulate a > web browser and for each use case go through all the important > branches. It worked well and the system test caught a lot of errors as > it exercised the whole system quite thoroughly. > > I had a common base class for my JUnit based HtmlUnit tests where I > had defined helper some methods which made the tests read pretty much > like normal English (ie clickButton, fillTextField etc). > > That project was not heavy on JavaScript, at all. In fact it only had > some JavaScript in a couple of very special places. And for those > cases HtmlUnit worked flawlessly. > > For this project, which is using Wicket, there will be more JavaScript > and AJAX behavior. At the moment it's the normal AJAX which Wicket is > able to generate. Later on there will defenitely be even more and we > will most likely integrate the application with jQuery or MooTools. > > I've been reading some more. Earlier I dismissed Selenium but it's > looking more attractive to me now. Being able to take screenshots at > certain places might come in handy as it will make it easier to see > that the layout is consistent over different browsers. Also the > WebDriver* looks like a nice way to write the tests, equally nice to > my way using helper methods. > > * http://google-opensource.blogspot.com/2009/05/introducing-webdriver.html > > If you do not have any test which acts on the presentation layer (ie > from the "outside", as a real web browser [Selenium or others] or a > simulated one [HtmlUnit and others]) could you explain why not? > > If you have these sorts of tests: > > How do you decide on what to test? (I went with use cases and the most > important paths within them) > > Which technology do you use for the tests? > > What pros and cons do you see with your way of doing things? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > -- Clint Popetz http://42lines.net Scalable Web Application Development --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
