Overall I would say that Selenium is the way to go for testing web applications and
Maven Selenium for java web applications, but when it comes to load testing I’ve had better luck with JMeter.

Emulating a browser is not the same thing as running it in a browser

I have to agree, it is terribly slow, but we just run it on our dev server every night, and get an email every morning with newly introduced bugs.

It really works perfectly for us.

It is a bit of a bruteforce:

It is quite possible to test Ajax app with Selenium. I successfully test a complex Ajax app built with Dojo for living. Testing ALL the app functionality and performing stress test using the same techniques.

Imagine a Dojo grid that is running in a separate thread in the browser and updating itself every so often, showing the user bids placed by other users in close to real time. Thus the user in question DOES NOT make any interaction with the page at all. No posts, no mouse clicks nothing. Yet the data is changing on the page and the change has to be tested.

I had to write a harness for Dojo widgets using HTMLParser, UI Declaration and some repeaters. But once written it is quite possible to parse the HTML that Dojo throws in to the browser. The DOM will change under us so testing DOM in Ajax app is rather pointless. We are never guaranteed to see an expected value in a static unit of time in an asynchronus app. Therefore making a single call to find an object and verify its value will not work.

More over, the value in question may be in the DOM but is hidden from the user and therefore not “seen” on in the browser window. Dojo has a lot of stuff like that.

Ajax is fluid so the tests must be fluid too.

The solution is to repeatedly capture the HTML from the browser,

… selenium.getHtmlSource(); …

parse it and interrogate the snapshot with use of a repeater class callback that looks something like this:

class Repeater{

public final static int TIMEOUT = 10000;
private static final int PAUSE = 250;

public static interface RepeaterCallback {
T whatToRepeat();
}

public static T repeat(long timeout, RepeaterCallback repeater) {
return repeat(timeout, PAUSE, repeater);
}

public static T repeat(long timeout, long pause, RepeaterCallback repeater) {
long exitTime = System.currentTimeMillis() + timeout;
while (true) {
T result = repeater.whatToRepeat();
if (result != null) return result;
if (System.currentTimeMillis() + pause >= exitTime) return null;
if (pause > PAUSE)
sleepNoThrow(pause);
else
sleepNoThrow(PAUSE);
}
}

}

The pattern is: Build, Operate Check.

Fire up the repeater with a given time out. And inside the callback call your test code. The test code will grab the HTML from the page in to an immutable variable and interrogate it. If unsuccessful (the value not found) it will repeat the process again and again until it either finds what you are looking for or times out.

Wrap the test case in to a method and:

@Test
public testSomething(){
MyTestParameters param …..
setupMyTest(param);
changeCondition(param);
assertEquals(“ExpectedValue”, testSomethingInAjax(param));
}

private String testSomethingInAjax(final MyTestParameters param) {
return Repeater.repeat(15000, 0, new Repeater.RepeaterCallback() {
public String whatToRepeat() {
return findExpectedValue(param);
}
});
}

private setupMyTest(MyTestParameters p){
// build test conditions
}

private changeCondition(MyTestParameters p){
// mock something, perform some actions
}

private String findExpectedValue(MyTestParameters p){
// Test the results in with use of the repeater
// return pass or fail
}

With a little code you can test anything in GWT, Dojo, Yahoo tool kit etc etc.
Wrap your UI components in to java classes with use of parser and test the expected value with a repeater, because you can NEVER be sure that the value will be there when you expected

Just my $0.02

One approach to making Javascript-heavy apps testable using static, outside-browsr verification is to decompose the content of each page into a series of components, each one available on it’s own URL.