One of the critical failings of automated web application testing comes when existing (previously recorded) test cases break due to changes with web infrastructures and back-end changes. Organizations invest significant time and money in building test infrastructures and recording automated tests, to find that far too often tests break when changes are made to minor content or page structure.

Why Tests break:

Simply speaking the most frequent reason for test cases breaking in modern testing frameworks (assuming you are past the evils of First Generation test frameworks) is due to the addressing of elements within a target page. More often than not the element addressing is too granular. What we mean by “granular” is that page elements (nodes) are addressed (located) in a very page structure specific manner. Almost all testing products claim to write succinct and robust test cases but in reality nothing is further from the truth. Test cases can easily be fragile.

How LiquidTest handles page changes:

From day one, the LiquidTest development team was well aware of the “achilles heel” of Second Generation testing frameworks. Generally speaking, the LiquidTest recording element locator tries to build test cases that will not break with minor or even major page changes. The basic searching algorithm (without getting too technical) utilizes the following; unique text, ID, name, value and lastly XPath’s to locate elements. The reason the XPath is the last item we use (only if forced), is because it is the most granular and more likely to break upon page structure changes.

Example pages:

We will demonstrate how LiquidTest handles the following two page variations;

Result!

The following is the LiquidTest recorded test case, for both of the HTML page variations:

public void myTest() {
    browser.load("http://localhost/test.html");
    // Check the "Hello World" is on the page
    assertEquals("Hello World", browser.getValue("Hello World"));
}

The test case records exactly the same on both pages! This demonstrates that the test case will not break between page layout changes or changes to the page style (or content). The content addressing plays an important role in making sure test cases are robust and do not break between layout and style changes.

Does the test case replay?

Why?

It all comes down to smart robust addressing.

STOP! But what if I want page changes to be noticed? Simple answer: Just assert the structure of the document, using the DOM inspector to add assertions.