This part is still under work. It does not yet compare to more recent frameworks such as Intern or environment-specific ones such as Capybara.

The scenario used throughout this comparison is the DuckDuckGo example, as defined in the tutorial.

If we were to use the current testing tools, we would write this test in a very imperative way.

For example, with Watij (a Java API over the official Selenium API, adding some sugar and abstraction over it):

import org.watij.webspec.dsl.WebSpec;

public class ZeroClickBoxTest {
	public static void main(String[] args) {
		WebSpec spec = new WebSpec().mozilla();
		spec.open("https://duckduckgo.com");

		spec.find.input().with.name("q").set.value("Toto");
		spec.find.input().with.type("submit").click();

		spec.findWithId("zero_click_heading").shouldExist();
		spec.findWithId("zero_click_heading").shouldHave("Meanings of Toto");
	}
}

This is quite readable, thanks to the Watij DSL.

However, this is not so maintainable. Of course, for such a small amount of code, this is not a problem, but let’s consider the full codebase: how can we architecture those tests to avoid duplication? More importantly, how can we ensure minimal effort if we change the layout of the page?

We could try and factor all DOM definitions in variables:

public class ZeroClickBoxTest {
	public static final String	SEARCHBOX_FIELD_NAME = "q",
					ZEROCLICKHEADING_ID = "zero_click_heading",
					AMBIGUOUS_LOOKUP_TERM = "Toto";

	public static void main(String[] args) {
		WebSpec spec = new WebSpec().mozilla();
		spec.open("https://duckduckgo.com");

		spec.find.input().with.name(SEARCHBOX_FIELD_NAME).set.value(AMBIGUOUS_LOOKUP_TERM);
		spec.find.input().with.type("submit").click();

		spec.findWithId(ZEROCLICKHEADING_ID).shouldExist();
		spec.findWithId(ZEROCLICKHEADING_ID).shouldHave("Meanings of " + AMBIGUOUS_LOOKUP_TERM);
	}
}

Ok, this is now a bit easier to maintain: if we ever change the DOM, we know where to look for redefinitions.

However, if we now want to access the header of the Zero Click Info box in another test, how are we going to do this? spec.findWithId(ZeroClickBoxTest.ZEROCLICKHEADING_ID)? How long until the cross-references become impossible to manage? In which test should those definitions fit? Plus, there’s a single block of code that does setup, actions, and assertions…

All of this leads to very lowly cohesive tests and tight coupling between DOM description and inbetween tests. As Steven Hazel from SauceLabs put it: “We’re the cavemen of browser tests”.

Hoping that you now have a basic understanding of the issues Watai tries to solve, let’s describe the architecture it offers: