Playwright-Tests prüfen, ob sie noch ihre Aufgabe erfüllen

Automatisierte Tests sind das Rückgrat moderner Softwareentwicklung – doch was passiert, wenn sie trotz grüner Statusleuchten längst nicht mehr das testen, was sie eigentlich sollen? Diese Frage treibt viele Teams um, doch eine Lösung fehlte bisher. Ein neues System kombiniert Playwright-Tests mit Produktanforderungen und Git-Historie, um sogenannte „Test-Drift“ zu erkennen. Das Problem: Über die Zeit werden Tests häufig angepasst, Assertions entfernt oder Anforderungen ignoriert, ohne dass dies jemals auffällt. Das Ergebnis? Tests, die zwar bestehen, aber längst nicht mehr die gewünschte Funktionalität validieren.

Warum bestehende Tools bei Test-Drift versagen

Tools wie GitHub Copilot oder KI-Assistenten wie Claude sind hervorragend darin, Code zu generieren oder Syntaxfehler zu erkennen. Doch sie scheitern an der eigentlichen Herausforderung: dem Verständnis, ob ein Test überhaupt noch das prüft, was das Produktteam ursprünglich verlangt hat.

• Sie analysieren aktuellen Code, nicht den Kontext über die Zeit
• Sie erkennen keine semantischen Lücken zwischen Anforderungen und Implementierung
• Sie bieten keine historische Perspektive auf Teständerungen

Ein klassisches Beispiel: Ein Login-Test überprüfte ursprünglich drei Fehlerfälle, doch im Laufe der Zeit wurden zwei Assertions entfernt – die Tests bestehen weiterhin, aber die ursprüngliche Abdeckung ist verloren. Erst ein System, das Jira-Anforderungen, Git-Änderungen und Testcode verknüpft, kann solche Defizite aufdecken.

Wie RAG und Git-Historie Test-Drift aufdecken

Das neue System nutzt eine Kombination aus Retrieval Augmented Generation (RAG) und Versionsanalyse, um semantische Abweichungen zu identifizieren. Der Prozess lässt sich in fünf zentrale Schritte unterteilen:

1. Anforderungen aus Jira extrahieren

Das System analysiert offene und geschlossene Jira-Tickets, um die ursprünglichen Produktanforderungen zu erfassen. Dazu gehören:

• Erwartete Verhaltensweisen (z. B. „Login mit falschem Passwort zeigt Fehlermeldung X an“)
• Validierungsszenarien (z. B. „Nach erfolgreichem Login wird die Dashboard-Seite geladen“)
• Priorisierte Features (z. B. „Zwei-Faktor-Authentifizierung muss unterstützt werden“)

Diese Daten werden als semantische Referenz genutzt, um später zu prüfen, ob Tests noch alle kritischen Pfade abdecken.

2. Test-Intent aus Playwright-Code ableiten

Jeder Playwright-Test wird auf seine tatsächliche Validierungslogik hin untersucht. Das System identifiziert:

• Alle Assertions und ihre Bedingungen
• Die getesteten Nutzerflüsse (z. B. „Anmeldung → Dashboard → Abmeldung“)
• Abhängigkeiten zwischen Tests (z. B. „Test A setzt Zustand für Test B voraus“)

Dabei werden auch dynamische Elemente wie Variablen oder externe API-Aufrufe berücksichtigt, um sicherzustellen, dass die Tests nicht nur syntaktisch, sondern auch semantisch korrekt sind.

3. Git-Historie auf Änderungen analysieren

Die Versionskontrolle ist der Schlüssel zur Erkennung von Test-Drift. Das System untersucht:

• Welche Assertions in der Vergangenheit entfernt oder modifiziert wurden
• Wann und warum Änderungen vorgenommen wurden (z. B. „Assertion für Dashboard-Ladezeit entfernt – Performance-Optimierung“)
• Ob neue Anforderungen umgesetzt, aber nicht getestet wurden

Ein besonders kritischer Fall: Ein Test wurde vor sechs Monaten angepasst, um ein neues Feature zu unterstützen, doch die ursprüngliche Kernfunktionalität (z. B. Fehlerbehandlung) wurde dabei übersehen. Solche Lücken bleiben oft unbemerkt, bis sie im Betrieb auftreten.

4. RAG für kontextuelles Verständnis nutzen

Hier kommt die Stärke von Retrieval-Augmented-Generation-Modellen ins Spiel. Das System:

• Erstellt semantische Embeddings der gesamten Codebasis
• Durchsucht historische Commits nach ähnlichen Testmustern
• Vergleicht aktuelle Tests mit bewährten Implementierungen in anderen Teilen des Projekts

Beispiel: Ein neuer Test für die Passwort-Reset-Funktion enthält keine Validierung für ungültige E-Mail-Adressen. Das System durchsucht die Codebasis nach ähnlichen Tests (z. B. Login-Validierung) und schlägt vor, die fehlende Logik aus auth/error.spec.ts zu übernehmen.

5. Semantische Drift detektieren und melden

Im letzten Schritt vergleicht das System die extrahierten Daten mit einer vorher definierten Schwelle. Bei Abweichungen wird eine Warnung generiert, die folgende Informationen enthält:

⚠️ Test-Drift erkannt in: login.spec.ts
Fehlende Abdeckung:
- Validierung der Fehlermeldung bei ungültigem Login
- Prüfung der Ladezeit des Dashboards

Historie:
- Assertion für Dashboard-Sichtbarkeit vor 3 Commits entfernt
- Neue Validierung für Passwortstärke hinzugefügt

Empfohlene Maßnahmen:
- Füge Assertion aus auth/error.spec.ts hinzu
- Aktualisiere Testdokumentation in README.md

Aktuelle Abdeckung: 65 % (Ziel: 90 %)

Der größte Mehrwert: Wiederverwendung bestehender Lösungen

Das System geht über reine Fehlererkennung hinaus. Bei identifizierten Lücken schlägt es nicht nur vor, was fehlt, sondern wie es bereits anderswo im Projekt umgesetzt wurde. Dies fördert:

• Standardisierung – Alle Tests nutzen die gleiche Logik für wiederkehrende Validierungen
• Wissensweitergabe – Neue Teammitglieder lernen von bewährten Implementierungen
• Schnellere Fehlerbehebung – Entwickler müssen nicht bei null anfangen

Ein konkretes Beispiel: Ein Test für die Registrierungsfunktion fehlte die Überprüfung von Sonderzeichen im Benutzernamen. Statt eine neue Validierung zu schreiben, verwies das System auf eine bestehende Implementierung in user/validation.spec.ts und schlug vor, diese zu übernehmen.

Die technische Umsetzung: Eine Mischung aus Präzision und KI

Das System basiert auf einer robusten, aber flexiblen Architektur:

├── jira_client.py          # Extraktion von Anforderungen
├── playwright_parser.py    # Analyse von Testcode
├── git_history.py          # Versionsverlauf auswerten
├── rag_engine.py           # Semantische Suche mit ChromaDB
├── drift_detector.py       # Vergleich von Intent vs. Implementierung
└── llm_reasoner.py         # Claude API für finale Analyse

Die Kernkomponenten im Detail:

• ChromaDB: Vektordatenbank für schnelle Ähnlichkeitsvergleiche zwischen Code-Snippets
• sentence-transformers: Lokale Embeddings für Code und Anforderungen (keine Cloud-APIs nötig)
• Ollama: Lokaler LLM für die Generierung von Handlungsempfehlungen
• Jira API: Direkte Anbindung an Ticket-Systeme für Echtzeit-Anforderungen

Ausblick: Was kommt als Nächstes?

Das System befindet sich in der aktiven Weiterentwicklung. Geplante Erweiterungen umfassen:

• Runtime-Validierung: Integration von Playwright-Tests in CI/CD-Pipelines, um Verhalten zur Laufzeit zu prüfen
• Automatische Korrekturen: Vorschläge für sichere Testanpassungen basierend auf historischen Patterns
• Framework-Unterstützung: Erweiterung auf Cypress, Selenium oder Jest
• Bessere Abfragegenauigkeit: Feinabstimmung der RAG-Parameter für komplexe Codebasen

Die entscheidende Frage: Prüfen Ihre Tests noch das Richtige?

Automatisierte Tests sind nur so gut wie ihre Abdeckung und Aktualität. Viele Teams investieren hohe Ressourcen in Testautomatisierung – doch ohne Mechanismen zur Erkennung von Test-Drift bleibt ein kritischer Blind Spot. Dieses System bietet einen ersten Schritt, um sicherzustellen, dass Tests nicht nur bestehen, sondern auch weiterhin die Produktanforderungen korrekt widerspiegeln.

Die Technologie dahinter ist kein Allheilmittel, aber ein mächtiges Werkzeug, um die Qualität von Tests langfristig zu sichern. Die Herausforderung bleibt: Wie stellen Sie sicher, dass Ihre Tests auch in sechs Monaten noch das testen, was sie heute sollen?

Diskutieren Sie mit: Wie gehen Sie mit Test-Drift in Ihrem Team um? Nutzen Sie bereits Tools wie RAG oder Git-Analysen für die Testpflege?