RE: testing Tapestry applications (in general) [I]

[Paul Field <pa...@db.com>]

Classification: For internal use only 

You may also find Tapestry Testify useful (http://tapestry.formos.com/nightly/tapestry-testify/) - it's designed for the class of tests where you want to test the web aspects of your application (particularly in a unit-test style) but aren't concerned with browser functionality (e.g. Javascript).

On my projects, we used Selenium to drive tests of browser behaviour (Javascript etc) and to drive smoke tests of a complete running system. We used Testify to do unit testing of pages/components and (integrated with Fitnesse) to do acceptance tests where the web was involved (e.g. when the user does A,B,C then the page shows a table like this: ..... ). And then JUnit etc... to do the non-web unit testing.

Best wishes,
Paul



-----Original Message-----
From: Christian Köberl [mailto:tapestry.christian.koeberl@gmail.com]
Sent: 04 November 2011 18:55
To: Tapestry users
Subject: Re: testing Tapestry applications (in general)

2011/11/04 15:01, Markus Johnston:
> We very much would like to start writing view and controller tests.  I 
> was wondering what other Tapestry users are doing, as far as testing 
> is concerned.  What problems have you run into?  What tools or 
> approaches have you found that work especially well?

We have a quite big application (>200k lines) and needed some integration/acceptance end-to-end tests (as an addition to our unit tests).

Our first approach were TestNG tests based on Selenium 1.x and backend calls in the same VM as the application itself. The pros are that you can use the backend directly but you cannot test the app in the target environment. Another problem is that the QA and our customer cannot understand the TestNG specs. We also had big compatibility problems with Selenium and browsers.

Our current tests are built on BDD with cuke4duke with Selenium 2.x web driver. The tests run standalone and can be run against our QA or other environments. We are porting our old tests when we're changing/refactoring stuff.
Our experience with this stack:
cuke4duke is a Ruby port and not a 1st class JVM citizen, so you get some problems. That's why we think about migrating to JBehave - but that's no big deal because it works exactly the same. Selenium web driver is very good and also works perfectly with IE and different versions of Firefox. For acceptance tests and especially for UI tests consider to organize your tests in layers (see http://cuke4ninja.com/chp_three_layers.html).
We have a testhelper for making direct backend calls through Spring remoting - but just for things you cannot do via UI.

A really good book about organizing your builds and tests (and especially about automated testing) is Continuous Delivery from Jez Humble and David Farley: http://amzn.to/qy2rc5

After all tries (and some failures) I'd advise this:
 * Use BDD if you need to communicate tests in any way, use JUnit/TestNG otherwise
 * Layer your tests in workflows and technical stuff
 * Use Selenium 2.x web driver for UI tests
 * Write tests that run against any environment (your local started IDE instance, your QA server - even your prod environment)

Hope this helps ...

--
Chris

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


---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.

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