share

End-To-End-Testing (E2E)

Vor Kurzem stand das „One-Week-Off“-Programms der marmalade GmbH für mich auf dem Plan. Dabei handelt es sich um ein Angebot an die Mitarbeiter, sich eine Woche aus dem regulären Tagesgeschäft heraus zu nehmen und mit einem Thema ihrer Wahl zu beschäftigen.

Für mich fiel die Wahl auf die Thematik des End-To-End-Testings (E2E). Mittels dieser Methode können Webapplikationen automatisiert hinsichtlich ihrer zugrunde liegenden und konzipierten Funktionalitäten getestet werden.

Das E2E-Testing kann verschiedene Akzeptanztests, wie bspw. User-Login oder Interaktionen innerhalb der Website (z.B. „Der User ruft Seite x auf, klickt auf den Button y und erwartet, dass die Information z erscheint“). Aber auch komplexere Nutzerinteraktionen können betrachtet werden. Beispielsweise ein kompletter Kaufprozess startend vom Besuch einer Katergorieseite, über die Auswahl eines Artikels, Hinzufügen in den Warenkorb und schließlich der Kaufabschluss, so dass der komplette Checkout Prozess automatisiert getestet werden kann.

Meine Zielstellung umfasste die Betrachtung und Evaluierung von drei E2E-Testingtools anhand eines konkreten Kundenbeispiels.

In diesem Artikel möchte ich gerne meine Eindrücke schildern. Dabei ist mir wichtig zu betonen, dass dies kein Tech-Talk wird. Im Fokus steht somit weniger der Code, als vielmehr die tatsächlichen Erfahrungen. Wer sich aus technischer Sicht tiefer für das Thema interessiert, dem kann ich die ausführlichen Dokumentationen der vorgestellten Tools empfehlen.

Bei den Tools handelt es sich um:

Für die Evaluierung sollten folgende Fragen beantwortet werden:

  1. Wie groß ist der Aufwand, das jeweilige Tool zu installieren?
  2. Wie zuverlässig funktionieren die Tests?
  3. Wie lässt sich das Tool in unseren CI-Prozess integrieren?

Kriterien:

  • Zu 1. Die Maßgabe in diesem Punkt war das Tool innerhalb von maximal 30 Minuten installiert und erste, einfache Tests geschrieben zu haben. Alle drei Tools bieten einen „Getting Started Guide“. Das Installieren und konfigurieren war somit in allen Fällen ohne größeren Aufwand möglich und schnell abgeschlossen.
  • Zu 2. Für mich funktioniert ein Test zuverlässig wenn er, sofern unter gleichen Bedingungen durchgeführt, reproduzierbare Ergenisse liefert.

Als ersten Test hatte ich definiert: „Rufe die Startseite auf und klicke auf den Link, der zur Login-Seite führt“. Die Syntax ist natürlich bei allen Tools unterschiedlich. Im Kern arbeiten diese jedoch alle nach einem ähnlichen Muster. Deshalb hatte die Syntax für mich in der ersten Betrachtung keine größere Relevanz.

In der Zuverlässigkeit des Tests zeigten sich hier bereits erste Unterschiede:

Sowohl Cypress als auch TestCafé haben den Test problemfrei abbilden können. CodeceptJS jedoch hat eine Fehlermeldung angezeigt, welche aussagte, dass das anvisierte Element (der Link zur Login-Seite) nicht gefunden werden konnte. Als ich  nach 15-minütiger Fehlersuche, dem Prüfen des Guides sowie der Recherche bzgl. der Fehlermeldung keine Lösung finden konnte, habe ich diesen Test mit CodeceptJS übersprungen.

Im nächsten Testfall wollte ich die Login-Funktion testen. Die Definition lautete demnach: „Gehe auf die Login-Seite, fülle die Input-Felder für E-Mail/ Passwort aus und klicke auf den Submit-Button“. Anschließend erwarte ich auf einer Seite zu sein, die „Hallo {username}“ enthält.

Auch hier liefen Cypress und TestCafé reibungslos durch. CodeceptJS hatte erneut das Problem, ein bestimmtes Element zu finden. In diesem Fall den Submit-Button.

Ob dieses Verhalten nun auf eine von mir fehlerhafte Implementierung des Tests oder auf das Tool selbst zurückzuführen ist kann ich nicht beurteilen. Für mich war entscheidend: In zwei von drei Tools funktionierten diese einfachen Tests ohne Probleme. Bei einem Tool müsste ich zusätzliche Zeit investieren, um die einfachen Tests zum Laufen zu bringen.

Punktsieg für Cypress und TestCafé.

Nach diesem ersten Beschnuppern der Tools, wobei alles noch stark an der Oberfläche gekratzt hat beschloss ich, mich näher mit ihnen zu beschäftigen. Angefangen habe ich dabei mit Cypress.

So nahm ich mir einen Vormittag um die Cypress Dokumentation von oben bis unten zu lesen. Dabei fand ich bereits viele interessante Aspekte des Tools, mit denen ich einige projektspezifische Testfälle abdecken könnte. Anstatt nun also direkt die nächste Doku zu lesen wollte ich das gelesene in der Praxis umsetzen.

In meinem Beispielprojekt gibt es die Besonderheit, dass bei der Nutzerinteraktion viel mit Asynchronität und AJAX-Requests gearbeitet wird. Hier ist demnach die Herausforderung, auch dies in den Tests sauber abbilden zu können. Sobald der Nutzer beispielsweise eine Versandart wählt wird mittels JS ein AJAX-Request abgeschickt, welcher die Zahlarten zurückgibt.

Der Test muss also Folgendes abbilden können: „Wähle Zahlart x aus und warte, bis der Request auf die Url ‚/xyz‘ beantwortet wurde. Anschließend erwarte ich, dass die Zahlart y verfügbar ist“.

Cypress kann diesen Fall bereits behandeln, ohne dass ich etwas zusätzlich konfigurieren muss. Das Tool wartet standardmäßig maximal 4 Sekunden ab, ob ein bestimmtes Element vorhanden ist. Zusätzlich kann definiert werden, dass ein bestimmter AJAX-Request abgewartet werden soll bevor weitere Testschritte durchgeführt werden.

Motiviert durch die schnelle Implementierung und Zuverlässigkeit der bisherigen Tests mit Cypress beschloss ich, komplexere Testscases zu definieren. So setzte ich das eingangs erwähnte Szenario des Weges bis zum Kaufabschluss um. Erneut klappte die Realisierung des Testcases relativ schmerzfrei. In weniger als 80 Zeilen Code konnte ich den kompletten Checkout Prozess abbilden.

Neben der problemfreien Implementierung der Tests gibt es weitere Punkte, welche bei Cypress positiv auffallen:

  • Cypress bietet eine GUI, welche den zu testenten Browser einbindet und dort direkt für den Anwender sichtbar die Tests durchführt. Dabei wird für jeden Test ein Snapshot angelegt. Dies ermöglicht, wenn beispielsweise ein Test fehlschlägt nachzuvollziehen, wie die Seite zu diesem Zeitpunkt aussah.
  • Wird Cypress in den CI-Prozess integriert bietet die Cloud-Plattorm „Cypress Dashboard“ die Möglichkeit, den im CI-Prozess durchgeführten Test zu visualisieren. Damit ist es für Projektmanager oder Shop-Betreiber einfacher zu ermitteln, weshalb ein Test ggf. fehlgeschlagen ist, ohne tiefere Coding Kentnisse zu besitzen.

Aufgrund dieser ersten Erkenntnisse und Eindrücke beschloss ich, als „proof of concept“, Cypress bei einem unserer Projekte in den CI Prozess zu integrieren und auf der Stage-Umgebung testen zu lassen.

Der Abschluss dieses Schrittes steht noch aus. Sobald dies durchgeführt wurde kann, für Cypress, die Frage „Wie lässt sich das Tool in unseren CI Prozess integrieren?“ beantwortet werden.

An dieser Stelle ist bereits klar, dass im Laufe der Woche mein ursprüngliches Ziel, drei Tools nebeneinander zu stellen und zu evaluieren der Idee eines „Proof of Concept“ gewichen ist. Stattdessen ist aus der Intention, mich in ein neues Thema einzuarbeiten, ein direktes Anwendungsszenario für unser Daily-Business entstanden.

Blogbeitrag von Alexander Hagemeier (Frontendentwickler marmalade GmbH)

Anna-Maria Roßdeutscher

Frau Roßdeutscher obliegt neben der Unterstützung unserer Geschäftsführung auch die Buchhaltung und die Organisation des Büroalltags.