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
