Die günstigsten Tests für Legacy-Code mit Cypress.io

Für Legacy-Applikationen geeignet

In meiner Arbeit als Freelancer sehe ich viele Testansätze in der Praxis und oft scheitert die Implementierung von Tests schlicht am Budget oder diese werden nach anfänglicher Implementierung nicht mehr laufend aktualisiert und ausgeführt.

So sinnvoll Tests von einzelnen Einheiten mit PHPUnit o.ä. sind, so aufwändig ist es leider auch, diese nachträglich in (Legacy-)Anwendungen zu implementieren, wenn diese nicht von Anfang an berücksichtigt wurden. In der Regel muss dafür Code umgeschrieben, Dependency Injection eingeführt, viele umständliche Mocks erzeugt oder umfangreiche Testing-Datenbank-Setups angelegt werden.

Frontend-Tests mit Cypress.io gehen hier einen anderen Weg und testen das tatsächliche Ergebnis, das der Kunde sieht in dem Tool, das der Besucher nutzt: den Browser. Dies hat den riesigen Vorteil, dass kein bestehender Code umgeschrieben werden muss für die Tests, sondern diese nachträglich einfach basierend auf dem tatsächlichen Shop-Frontend gebaut werden können. Außerdem wird das eigentliche Ergebnis für den Kunden getestet und nicht irgendein interner Schritt dazwischen.
Und wenn die Tests sinnvoll geschrieben sind, besteht auch nicht die Gefahr, dass bei jeder Frontend-Änderung die Tests auch angepasst werden müssen.

Minimaler Overhead

Ich habe in meiner Praxis schon hunderte Frontend-Tests mit Cypress.io implementiert. Aus meiner Erfahrung liegt der Aufwand für die Ende-zu-Ende-Tests je nach Projekt und Software bei ca. 20-30%, was wirklich extrem wenig ist. Die Vorteile und Einblicke in die Applikation, die man dadurch erhält sind aber extrem wertvoll und haben die Mehrkosten in der Regel innerhalb kürzester Zeit amortisiert.
Im Gegensatz dazu muss man für Unit-Tests insbesondere bei Legacy-Applikationen in der Regel mit 50% und mehr rechnen.

Ein Vorteil von Cypress.io ist, dass die Tests sehr einfach geschrieben werden können. Es wird kein PHP- oder ReactJS-Entwickler benötigt, sondern bereits simple JavaScript-Kenntnisse und eine Einführung in die Software sind vollkommen ausreichend für die ersten Tests. Dies ermöglicht meinen Kunden, eine schnelle Übernahme und weitere Implementierung der von mir erstellten Tests.

Aufwand für Tester sparen

Sobald die Cypress.io Tests aufgesetzt sind, laufen diese automatisch in festen Intervallen oder auf manuelles Anstoßen. Damit können sich Ihre Tester auf die wirklichen Edge-Cases oder Smoke-Tests konzentrieren, sofern diese nicht auch mit Cypress.io-Tests abgedeckt werden können.

Nehmen wir an, Ihr Tester benötigt sonst für jedes Release-Testing 2 Stunden, dann reduziert sich die Zeit mit meinen Ende-zu-Ende Frontend-Tests auf nur wenige Minuten. Zudem können diese kontinuierlich laufen und somit auch Veränderungen in Live-Systemen zuverlässig überwachen.

Dokumentation von Veränderungen

Meine Cypress.io Frontend-Testsuite erstellt für jeden Testlauf ein Video und Screenshots und legt diese in der Cloud für eine gewisse Zeit ab, so dass Änderungen zuverlässig über die Zeit dokumentiert werden. Aus Versehen das HTML auf der CMS-Seite kaputt gemacht? Kein Problem, Sie erhalten innerhalb weniger Stunden eine Alert-Email und können den Fehler korrigieren.

Fragilität der Tests

Zum Einen ist das die Fragilität der Tests. Frontend-Tests basieren wie der Name schon sagt auf dem Frontend. Am Frontend werden aber auch mit die meisten Änderungen vorgenommen, d.h. hier mal eine CSS-Klasse geändert, da mal den Button verschoben, etc. Wenn man die Selektoren in der Testsuite ungünstig wählt, führt dies dazu, dass mit jeder Änderung auch der Tests wieder fehlschlägt und angepasst werden muss. Dies sollte unbedingt vermieden werden, da so auch das Vertrauen in die Frontend-Tests verloren geht und man schlussendlich unter Umständen sogar aufhört, die Frontend-Tests auszuführen oder laufend anzupassen.

Es ist daher essentiell, die Selektoren in den Tests sinnvoll zu wählen: zum einen unterstützt Cypress.io hier sogenannte Fuzzy-Selektoren, die zum Beispiel auf irgendeinen Text gehen können: cy.contains("Zur Kasse"). Zum anderen kann es auch sinnvoll sein, zusätzliche Attribute wie data-cy="button-checkout" einzuführen, die ein zuverlässiges Selektieren bei häufigen Änderungen ermöglichen.

Im Laufe der Zeit muss man hier einfach einen Kompromiss finden und sich insbesondere die als "flaky" markierten Tests in der Cypress.io Cloud genauer ansehen und überlegen, wie diese robuster implementiert werden könnten.

Längere Laufzeiten

Der zweite große Nachteil ist, dass die Tests im Vergleich zu Unit Tests in der Regel länger laufen, d.h. die Ausführungszeit ist länger. Dies hängt einfach auch damit zusammen, dass die einzelnen Seiten geladen werden müssen, die Tests ggfs. auf das Vorhandensein einzelner Elemente warten muss, etc. und lässt sich konstruktionsbedingt nur zum Teil optimieren.

Um dem entgegen zu wirken, gibt es verschiedene Strategien:

1. Zum Einen hilft es, die Tests zum Beispiel mit Tags entsprechend zu priorisieren und somit die Testausführung so zu beeinflussen, dass die kritischen Tests immer als Erstes abgearbeitet werden
2. Außerdem unterstützt die Cypress.io Cloud die Parallelisierung von Runs, so dass hier absolute Laufzeit eingespart werden kann
3. Desweiteren sollte man nicht wie z.B. bei Unit-Tests möglichst viele singuläre Tests implementieren, die jeweils nur 1 Überprüfung/Assertion haben, sondern es ist durchaus Best Practice, mehrere Zuweisungen zusammenzufassen