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
