Deine End-to-End-Suite braucht vier Stunden und Entwickler warten nicht mehr auf sie. Wie behebst du das?

Greif es an vier Fronten an: parallelisieren über Worker, Abdeckung die Pyramide runter verschieben, sodass API- und Unit-Tests langsame UI-Journeys ersetzen, doppelte und wertarme Tests streichen und das Setup beschleunigen, indem du Zustand über die API statt über die UI erzeugst. Dann teil die Suite so, dass ein schneller Ausschnitt Merges absichert und der volle Lauf nachts passiert.

Zuerst hole ich die Daten, denn zu raten, welche Tests langsam sind, liegt meistens daneben. Ich ziehe die Laufzeiten pro Test und finde fast immer eine kleine Zahl Tests, die einen unverhältnismäßigen Anteil frisst, oft wegen fester Sleeps oder weil das Setup über die UI läuft. Parallelisierung ist der schnellste strukturelle Gewinn, funktioniert aber nur bei sauber isolierten Tests, das heißt meist, zuerst geteilte Testdaten zu reparieren. Der größere Hebel ist die Neuverteilung. Ich schaue mir jeden End-to-End-Test an und frage, was er wirklich belegt. Ein Test, der durch sechs Screens läuft, um eine Validierungsmeldung zu prüfen, ist ein Unit-Test im Kostüm und gehört auf eine Schicht, wo er in Millisekunden läuft. Dann lösche ich, was Leuten unangenehm ist. Tests, die nie aus einem echten Grund fehlgeschlagen sind, Tests, die anderswo vorhandene Abdeckung duplizieren, Tests für Features, die niemand nutzt. Abdeckung, die mehr kostet als sie bringt, ist eine Last. Und ich mache Setup über die API, sodass ein Checkout-Test seinen Account und Warenkorb in zwei Aufrufen anlegt statt in fünfzehn Seitenladevorgängen. Zum Schluss teile ich auf: fünfzehn Minuten kritischer Pfad bei jedem Merge, volle Suite nachts.