Eine Testsuite, die vierzig Minuten läuft, wird nicht mehr lokal gestartet. Sie wird in die Pipeline geschoben, und dann geht jemand Kaffee holen. Ein paar Wochen später sind die Tests eine Formalität, die man abnickt, statt ein Werkzeug, mit dem man arbeitet. Genau da fängt der Qualitätsverlust an, lange bevor der erste Test rot wird.
Die gute Nachricht: Langsame Suiten sind fast nie gleichmäßig langsam. Die Zeit sammelt sich an wenigen Stellen, und die sind meistens dieselben. Hier sind die Hebel, in der Reihenfolge, in der sie sich lohnen.
Vibe Coding Schulung: in zwei Stunden zur deployten Landing Page
Remote, ohne US Abo, mit OpenCode und lokalen Modellen. Ihr baut live mit, statt zuzuschauen.
- Astro Projekt von der leeren Mappe bis zum Deployment
- OpenCode im Terminal, lokale Modelle über Ollama
- Daten bleiben im eigenen Netz, kein Abo bei US Anbietern
- Danach laufende Begleitung statt Zertifikat und tschüss
Zuerst die Haltung, dann die Technik
Drei Punkte, die den Unterschied zwischen einem Nachmittag Bastelei und echtem Fortschritt machen.
Messen, nicht raten. Notiert die Gesamtlaufzeit vor jeder Änderung und danach. Ohne Zahl vorher ist jede Optimierung Gefühl, und manche Änderung macht Dinge sogar langsamer.
Das Häufigste zuerst. Eine Fixture, die in jedem zweiten Test steckt, ist mehr wert als der eine besonders hässliche Report Test, den niemand anfasst. Sucht nach Breite, nicht nach Hässlichkeit.
Aufhören, wenn es zäh wird. Wer vier Stunden in eine Methode investiert und eine Sekunde gewinnt, hat die falsche Baustelle. Es gibt fast immer eine leichtere daneben.
Hebel 1: Messen, wo die Zeit hingeht
PHPUnit bringt die Grundlage schon mit. --log-junit liefert Laufzeiten pro Testfall, und die Liste der langsamsten Tests ist der erste Blick, den ihr braucht. Für den Blick in den Call Stack hilft ein Profiler wie Xdebug oder Blackfire an einem einzelnen langsamen Testlauf.
Bei den End to End Tests übernimmt das Cypress Cloud Dashboard: Laufzeiten pro Spec über die Zeit, dazu die Ausreißer. Wichtig ist die Reihenfolge — erst die Zahlen, dann anfassen. Fast jedes Team, das ohne Messung startet, optimiert am falschen Ende.
Hebel 2: Objekterzeugung entrümpeln
Der größte einzelne Posten in Integrationstests sind meistens die Testdaten. Eine Fabrik legt einen Nutzer an, der Nutzer braucht eine Firma, die Firma eine Adresse, und plötzlich entstehen für einen Test, der eine Zeile prüft, sieben Datensätze.
Der Trick: Assoziationen nicht per Default anlegen, sondern nur auf Anforderung. Baut sie als optionale Varianten und ruft sie dort auf, wo sie gebraucht werden. Der schnellste Weg, das zu prüfen: Kommentiert eine Assoziation testweise aus und schaut, wie viele Tests wirklich rot werden. Die Zahl ist regelmäßig kleiner als erwartet.
Hebel 3: Nebenwirkungen abschalten
In jeder gewachsenen Anwendung hängen Dinge an Events, die im Test niemanden interessieren: Suchindex aktualisieren, Historie schreiben, Mail verschicken, Webhook feuern, Cache Eintrag invalidieren. Diese Nebenwirkungen laufen in tausenden Tests mit und werden in einer Handvoll davon tatsächlich geprüft.
Sauberer Weg ist ein Testmodus pro Feature: standardmäßig aus, gezielt anschaltbar für die Tests, die genau dieses Verhalten prüfen. Kein globales Wegmocken, sondern ein bewusster Schalter. Das hält den Test ehrlich und die Suite schnell.
Hebel 4: Daten einmal statt tausendmal anlegen
Viele Testklassen erzeugen in jedem einzelnen Testfall dieselbe Grundlage neu. Wenn die Daten während der Klasse nicht verändert werden, reicht es, sie einmal anzulegen und danach in einer Transaktion zu arbeiten, die nach jedem Test zurückgerollt wird.
Ein Standardnutzer, der praktisch überall gebraucht wird, gehört einmal pro Lauf angelegt und dann wiederverwendet. Achtet dabei auf einen sauberen Datenbankzustand: Wenn irgendwo Daten außerhalb der Transaktion entstehen, bekommt ihr Tests, die je nach Reihenfolge mal grün und mal rot sind. Das kostet später mehr Zeit, als die Optimierung eingespart hat.
Hebel 5: E2E Tests nicht durch die UI quälen
Bei Cypress liegt der größte Gewinn fast immer im Setup, nicht im eigentlichen Test. Login über das echte Formular, Klick für Klick, in jedem Spec: Das sind schnell mehrere Sekunden pro Datei, die nichts prüfen, was nicht ohnehin ein eigener Login Test abdeckt.
Setzt den Zustand stattdessen direkt: Session wiederverwenden, Ausgangsdaten per Task oder API anlegen, und nur den Teil klicken, um den es im Test geht. Und wartet auf Bedingungen statt auf Sekunden. Feste Wartezeiten sind doppelt teuer, sie kosten Laufzeit und produzieren trotzdem wackelige Tests.
Hebel 6: Parallelisierung kommt zuletzt
Tests auf acht Runner zu verteilen sieht nach der schnellsten Lösung aus. Nur verteilt ihr damit auch jede unnötige Objekterzeugung auf acht Maschinen und zahlt sie achtmal. Parallelisierung ist ein Multiplikator, kein Fix.
Erst aufräumen, dann verteilen. Danach lohnen sich in der Pipeline die üblichen Griffe: Abhängigkeiten cachen, Container Images vorbauen, unabhängige Jobs nebeneinander laufen lassen. Wie das zusammenspielt, steht bei den CI CD Pipelines.
Warum das Thema 2026 dringender wird
KI Agents schreiben Tests schnell und gern. Das ist erst einmal gut, führt aber dazu, dass Suiten deutlich schneller wachsen als früher. Wer die Laufzeit nicht im Blick behält, steht in einem halben Jahr vor einer Pipeline, die niemand mehr abwartet. Und eine Pipeline, die niemand abwartet, ist kein Quality Gate mehr, sondern Dekoration.
Deshalb gehört die Laufzeit der Suite in dieselbe Liste wie Coverage und statische Analyse. Messt sie, macht sie sichtbar, und zieht eine Grenze, ab der optimiert wird. Wie so ein Setup im Alltag aussieht, steht im Überblick zu Vibe Coding und bei den Vibe Coding Best Practices.
Tests, die schnell genug bleiben
In der NCA Vibe Coding Schulung geht es genau darum: Agents arbeiten lassen und trotzdem Quality Gates behalten, die im Alltag durchlaufen. Termine auf Anfrage, kostenloses Kennenlernen vorab, danach transparente Minuten Abrechnung.
