views:

309

answers:

3

I have found out that for java automation testing better approach would be to use Cruise Control(java), JUNIT (java testing framework) along with Watij. Any further suggestions please. Any one who has succesfully integrated these tools and what limitations are found for this.

regards

A: 

We like to use WATIR for functional testing of web applications. It's a browser automation package for Ruby. Easy to learn and we haven't run into any roadblocks after writing many test cases.

Ken
Watij is also a used for functional testing of java web applications. I want to know the best appraoch for java. any idea
sam
Understandable. I like to write my code in java (compiled, type safe, etc) but write the test cases in ruby (less overhead, easier to read the tests, domain-specific language, etc).We were happy with WATIR so it WATIJ is the same quality it would be worth checking out. But I have no experience with it.
Ken
+1  A: 

One of my co-workers is a big fan of Watir which I'm guessing is similar to Watij. I like Selenium, and have been considering playing with Tellurium lately.

In any case, tying any of those together with a Continuous Integration engine like CruiseControl or Hudson (my favorite) is a great way to handle functional testing for web applications. And JUnit is great for unit tests and even integration tests.

Limitations to functional web application testing:

While you can tell a user to click on "the first item in the menu on the left-hand side", telling the computer to do the same isn't so easy. Web application testing frameworks can't look at the screen and readily discern what elements on the page constitute a menu. They need more specifics on what element to interact with, and that in turn requires some knowledge of how the HTML page is constructed. And as the page changes, so can the tests.

When every little change in one part of the page breaks the tests in other, unrelated parts of page, those tests are called "brittle". Making sure the tests are more stable takes some experience, just as it does in regular unit testing. For example, use element ID or name to refer to the elements on a page, not their full XPath (could be long and unreadable as well as brittle) or their text content (if it might change).

CoverosGene
+2  A: 

We generally try to test application on 3 levels:

  • Unit tests with JUnit. For this purpose we follow Dependency Injection patter and use mocked objects (based on JMock framework) when necessary.
  • Integration tests. These are also based on JUnit, but do not use mocked objects and test different layers of application, writing to database for example. For the purpose of basic data we follow the Object Mother pattern.
  • Acceptance tests, for this purpose we use Selenum.

For test automation and continuous integration, our projects are built with Maven and Hudson. One of the improvements we are looking into at the moment is using Groovy instead of Java for the tests.

Some of the issues we had to resolve: creation of basic data in test case setup (based on Object Mother pattern), organization of test suits since all tests can take a lot of time to run, dealing with duplication in test code and a lot of fiddling with Maven and Selenuim, but is definitely worth it in a long run.

Dan
Tellurium looks like Groovy on top of Selenium. Might be worth a look.
CoverosGene
Sounds interesting. Will take a look...
Dan