Automatisiertes Testen: Testautomatisierung mit Geb und ScalaTest

Von Angi Mathea, Daniel Börgers und Dennis Rieks

Der Traum, die eigene Arbeit zu automatisieren und einfach die Füße hochzulegen, ist wahrscheinlich jedem Entwickler schon einmal durch den Kopf geschossen. Besonders im agilen Arbeitsumfeld sind gewisse Automatisierungen allerdings tatsächlich unabdingbar - bei schnellen Releasezyklen müssen zum Beispiel Tests zumindest teilweise automasiert ablaufen. Dieser shortcut bietet alle notwendigen Informationen, um das automatisiere Testen mit Geb und ScalaTest durchzuführen. Im ersten Kapitel wird das Geb Framework für die Webautomation vorgestellt, während im zweiten Kapitel die Erfahrung mit der Verwendung von ScalaTest geschildert wird.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 20. Jan. 2017
• ISBN: 9783868027501

Buchvorschau

GmbH

1 Automatisiertes Testen: ein Erfahrungsbericht

Insbesondere im agilen Umfeld mit kurzen Releasezyklen oder Continuous Delivery ist ein automatisierter Test fast unabdingbar. Hier ist es ohne immensen Testaufwand unmöglich, für jedes Release einen kompletten manuellen Regressionstest zu realisieren. JUnit-Tests haben für die Komponententests bereits vielfach Einzug gehalten. Geplante automatisierte Oberflächen- und Behaviour-Tests sind dagegen eher die Ausnahme.

Das strategische automatisierte Testen fristet in der Softwareentwicklung vielfach noch ein Schattendasein. Dabei ist es für wiederholbare Smoke- und Regressionstests sehr sinnvoll. Außerdem eignen sich nicht alle Tests und Prüfungen für menschliche Wahrnehmung und menschliches Verhalten, also für die manuelle Ausführung. Ungeeignet sind z. B. Prüfungen, bei denen Texte verglichen werden müssen, insbesondere wenn diese nicht in der Muttersprache sind oder darüber hinaus noch über ein anderes Alphabet verfügen. Auch wenn innerhalb eines großen Menüs ein Punkt fehlt oder Überschriften zwar vorhanden sind, aber den falschen Text haben, sind dies Punkte, die einem menschlichen Betrachter vermutlich nicht auffallen – wenn er nicht ausgerechnet danach sucht. Bei Anbietern automatisierter Testtools kommt das automatisierte Testen gerne wie eine Lichtgestalt daher. Entsprechend hochgeschraubte Erwartungen bauen sich auf.

Unsere Anwendung läuft aktuell auf verschiedenen Plattformen (Multiplattform, Android/iOS, Desktop/Mobile) in zehn Übersetzungen (Multi Language) und auf vier unterschiedlichen Domänen (Multi Domain, COM Host, türkischer Host, brasilianischer Host, russischer Host). Anvisierte Wunschvorstellung war, für jeden Test bei dessen Aufruf festzulegen, auf welchen Plattform-Browser-Kombinationen (1 – x), für welche Sprachen (Angabe der zu prüfenden Sprachen, 1 – y) und für welche Domänen (1 – z) dieser laufen soll. In der vollen Ausprägung muss jeder Test x*y*z-mal laufen.

Wie alles begann

Folgende Ausgangssituation liegt vor: Für die vielen Workflows im Backend gibt es Unit-Tests. Improvements werden mit Features abgesichert, sodass sie leicht abgeschaltet werden können. Die Überprüfung der Anforderungen des Kunden bezüglich Aussehen und Verhalten der Anwendung wird manuell durchgeführt. Hierfür werden vom Kunden in den Implementierungstickets zusammen mit dem Entwickler Anforderungen und Abnahmekriterien definiert. Diese lassen sich von den Testern mit einem eigenen Schema in einen Testplan überführen, der manuell ausgeführt wird. Dieses Schema gibt Richtlinien für den manuellen Test vor, die neben explorativen Anteilen abgedeckt werden müssen. Beurteilt wird