recheck-web – ein etwas anderer Ansatz zur Testautomatisierung

Inhaltsverzeichnis

recheck-web ist ein Golden-Master-basiertes Testwerkzeug. Da es im Prinzip gerenderte Webseiten miteinander vergleicht, lassen sich damit auch Cross-Browser-Testing, Cross-Platform-Testing und andere Testszenarien umsetzen.

Um eine Anmeldung einer Webanwendung zu testen, könnte ein typischer Selenium-Test etwa so aussehen:

public class MySeleniumTe st {

    RemoteWebDriver driver;

    @Before
    public void setup() {
        driver =  new ChromeDriver();
    }

    @Test
    public void login() throws Exception {
        driver.get("https://assets.retest.org/demos/app/demo-app.html");

        driver.findElement(By.id("username")).sendKeys("Simon");
        driver.findElement(By.id("password")).sendKeys("secret");
        driver.findElement(By.id("sign-in")).click();

        assertEquals(driver.findElement(By.tagName("h4")).getText(), "Success!");
    }

    @After
    public void tearDown() throws InterruptedException {
        driver.quit();
    }
}

Das ist ein einfacher Test, der eine bestimmte URL öffnet, dann Eingabefelder anhand ihrer unsichtbaren Element-IDs findet, um Benutzernamen und Passwort einzugeben, und schließlich auf Login klickt. Wie derzeit üblich, verwendet der Test am Ende eine Unit-Test-Bibliothek, um das korrekte Ergebnis der Testausführung mit einer "assert"-Anweisung zu überprüfen. Konkret wird geprüft, ob der Text "Success!" angezeigt wird.

Mehr Infos

Die im Artikel verwendeten Beispiele finden sich auf GitHub. Zur Verwendung und Installation der gezeigten Werkzeuge gibt es ein ausführliches Tutorial auf heise Developer.

Jetzt können Entwickler das HTML der zu testenden Website ändern. Sie könnten zum Beispiel die
CSS-Deklaration <link href="./files/main.css" rel="stylesheet"> bearbeiten. Das Ändern eines einzelnen Zeichens der URL führt dazu, dass die Website ohne Formatierung angezeigt wird.

Diese Änderung entspricht jedoch einem Fehler. Wenn man den Test ausführt, zeigt er allerdings kein Problem und läuft immer noch fehlerfrei durch. Das ist eindeutig nicht das, was man von dem Test erwartet. Probiert sei nun stattdessen, die für den Benutzer unsichtbaren Element-IDs zu ändern oder zu entfernen. Da diese IDs nicht zu erkennen sind, hat die Änderung aus Benutzersicht keinen Einfluss auf die eigentliche Website. Aber wenn man den Test jetzt ausführt, ist zu sehen, dass er mit einer NoSuchElementException abbricht. Die für den Nutzer irrelevante Änderung hat den Test nicht nur fehlschlagen lassen, sondern auch seine Ausführung verhindert – ihn also "gebrochen". Tests, die größere Änderungen ignorieren, aber bei unsichtbaren brechen, sind der aktuelle Standard in der Testautomatisierung. Das ist im Grunde genommen das Gegenteil dessen, was man sich von den Tests wünscht.

Nun ist es an der Zeit, den Originaltest zu nehmen und den Selenium-Treiber in einen RecheckDriver zu stecken:

driver = new RecheckDriver(new ChromeDriver()); 

Bei entsprechender Projektkonfiguration ist sonst nichts weiter nötig. Die Prüfung mittels assert kann man nun löschen. Entfernt man das CSS von der Website, schlägt der Test plötzlich mit vielen Unterschieden fehl.

Ändern oder entfernen Entwickler stattdessen die Element-IDs, wird der Test trotzdem erfolgreich ausgeführt (funktioniert entsprechend auch mit Name, CSS-Klasse, XPath etc.). Diese Fähigkeit wird als "Unzerbrechlichkeits"-Feature von recheck-web bezeichnet. So sollten sich Tests verhalten: Änderungen, die für den Benutzer wichtig sind, erkennen und nicht an Änderungen brechen, die für den Benutzer irrelevant sind.