Re: System test for a Wicket based web application. Do you do it? How?

[Clint Popetz <cl...@42lines.net>]

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 <ke...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>



--
Clint Popetz
http://42lines.net
Scalable Web Application Development

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: System test for a Wicket based web application. Do you do it? How?

[Günther Enthaler <ge...@mac.com>]

To be honest, there's nothing wicket-specific about it. Testing AJAX is
pretty easy, just use waitFor* assertions to delay until the AJAX component
is loaded.

One slight irritation is that Wicket munges the id of its components, making
element identification a bit tedious, so I eventually wrote a custom element
locator.

Best thing is to just get in and install it, try it, take over one of the
provided stubs and modify it to drive your own application. It won't take
you long to get into the groove. The documentation is pretty good too.

Cheers,
Günther


Newgro wrote:
> 
> 
> stiq looks very promising. Can you please provide some small snippets 
> howto use it in correlation with wicket?
> 
> 

-- 
View this message in context: http://www.nabble.com/System-test-for-a-Wicket-based-web-application.-Do-you-do-it--How--tp23513449p23539242.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: System test for a Wicket based web application. Do you do it? How?

[Per Newgro <pe...@gmx.ch>]

Hello Günther,

stiq looks very promising. Can you please provide some small snippets 
howto use it in correlation with wicket?

Cheers
Per

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: System test for a Wicket based web application. Do you do it? How?

[Günther Enthaler <ge...@mac.com>]

I've been using  http://storytestiq.solutionsiq.com/ STiQ  for integration
testing on my current project. It's a mashup of Selenium & Fitnesse. It
makes for a really comfortable test construction & running environment. 

I've used JUnit driven Selenium tests in the past, but the tests were
impossible to read, and they weren't particularly refactorable (losing any
benefit of having them driven from code). 

Having the front end tests written in a user-legible DSL forces you to think
about the tests from the point of view of the end user. 

Commenting is a easy and natural thing to do in this environment. It
actually looks a lot like Literate Programming.

Many of the functional tests I'd written for this project exercised
execution paths around session timeouts, something that'd be difficult (or
impossible) to test from a unit-test perspective, but which were easy to
write in STiQ. 

The fact that the tests are running in the SOE is a comfort too.

It's apparently possible to drive it from JUnit/Maven/Ant/whatever, but I
haven't got around to doing that.

An similar FOSS alternative to STiQ is  http://www.fitnesse.info/webtest
WebTest , and an alternative to Selenium is  http://watij.com/ Watij 

-- 
View this message in context: http://www.nabble.com/System-test-for-a-Wicket-based-web-application.-Do-you-do-it--How--tp23513449p23519414.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org