Wer kennt das nicht: Oberflächen-Tests werden in vielen Projekte stiefmütterlich behandelt. Wenn überhaupt automatisierte Oberflächen-Tests existieren, sind sie meist schwer zu pflegen oder nicht wirklich stabil. Gerade vor dem Hintergrund von Continous Integration (CI) und Test Driven Development (TDD) ist das eigentlich ein unhaltbarer Zustand. Gerade Oberflächen-Tests sind extrem wertvoll, um kritischen Pfade abzutasten, z.B. als Smoke-Test vor einem Live-Deployment. Mit Thucydides ist es möglich, Oberflächen-Tests lesbarer, wartbarer und wiederwendbar umzusetzen. Dabei wird das Page-Object-Pattern umgesetzt, um diese Anforderung umzusetzen.
Thucydides – Projektstruktur
Die UI-Elemente werden dabei in den Page-Klassen logisch zusammengefasst und jegliche Benutzerinteraktion wird in den Step-Klassen gruppiert, wie z.B. das Klicken auf Buttons in der Oberfläche. Die Tests sind dann lediglich eine Kollektion von Steps, die Benutzereingaben reflektieren und das Ergebnis verifizieren.
Thucydides nutzt Selenium als technische Basis, erweitert es aber um verschiedene Locator-Stragien, z.B. für AngularJS:
Thucydides – Locator-Strategien
Außerdem können Tests neben der klassischen Java-Sprache auch in JBehave beschrieben werden. Über das integrierte Reporting, das auch in eine Maven-Site eingebunden werden kann, können die Tests einfach getrackt werden, was die Fehlersuche erleichtert. Denn jeder Benutzerschritt wird im Report einzeln ausgewiesen:
Thucydides – Mapping von Steps in Reports
Thucydides – Report-Beispielseite komplett
Eine ausführliche Vorstellung ist auf GitHub.io verfügbar.
