Multi-Agenten-System zur Automatisierung von React-Unit-Tests: Von Planung bis Mutationen
React-Entwickler stoßen oft auf die Herausforderung, Tests von Enzyme auf React Testing Library (RTL) zu migrieren. Die manuelle Umstellung von Hunderten Komponenten kann Monate dauern. LLM-gestützte Automatisierung verkürzt das drastisch: von einfachen Prompts bis hin zu einem Multi-Agenten-Pipeline mit Mutationsprüfung. Das System erzeugt, prüft und validiert Tests und integriert sich nahtlos in Ihren Workflow.
Fallstricke naiver Ansätze
Frühe Experimente mit ChatGPT lieferten fehlerhaften Code: TypeScript-Fehler, RTL-Antipatterns und fehlender Projektkontext. Das Modell spuckte generische Tests aus, die Mocks, State-Management und Routing ignorierten.
Ein N8N-Pipeline mit System-Prompt half ein wenig:
- Komponentenanalyse und Komplexitätsbewertung.
- Klassifizierung von Testfällen (einfach, mittel, komplex).
- Gruppierte Generierung mit Beispielen.
Aber ohne Ausführung im echten Projekt kompilierten die Tests nicht. Cursor mit IDE-Dateizugriff war ein Fortschritt: Es sah Imports und Typen, brauchte aber wiederholte Prompts zur Betonung von RTL-Best Practices.
Claude Code: Grundlage für Agents
Claude Code führte Agents mit isolierten Kontexten und Projektzugriff ein. Agents können Dateien einsehen und Befehle ausführen (ESLint, TypeScript, Jest/Vitest). Die unit-tester-Skill orchestriert den Pipeline und erzeugt Sub-Agents bei Bedarf.
Die .test-pipeline.yaml-Konfig speichert Projektspezifika: Mock-Pfade, State-Management, Test-Runner und Regeln.
Prototyp mit drei Agents
Basis-Pipeline:
- test-planner: Analysiert die Komponente (UI vs. Container) und plant Testfälle.
- test-writer: Erzeugt
.test.tsx-Dateien basierend auf dem Plan. - test-validator: Prüft Kompilierung und Ausführung (ESLint, TS, Tests).
Vorteile:
- Funktioniert mit dem vollständigen Projekt-Codebase.
- Selbstdurchprüfung der Ergebnisse.
- Agents spezialisieren sich auf Aufgaben.
- Projektkontext aus Konfig.
RTL-Philosophie-Review
Bestandene Tests garantieren keine Qualität. Der test-reviewer-Agent bewertet sie (1–10) nach:
- Testen von Verhalten, nicht Implementierung.
- Nutzung von Roles/Labels, Vermeidung von CSS-Klassen.
- Beschreibende Testnamen.
- Konstanten statt Magic Strings.
Bewertungen unter 9 lösen Revisionen aus (max. 3 Iterationen).
Mutationstests zur Verifikation
Schlüssel-Schritt: Sicherstellen, dass Tests Bugs fangen. mutation-planner erzeugt Mutationen pro Testfall:
- Button bei leerer E-Mail deaktiviert →
disabledentfernen. - Fehleranzeige → Render löschen.
- API-Aufruf → auskommentieren.
test-verifier führt sie sequentiell aus:
- Test besteht am Original ✅.
- Komponente sichern.
- Mutieren, Test scheitert ❌.
- Wiederherstellen, Test besteht ✅.
Ziel: 100% Erfassungsrate. Darunter? Überarbeiten (max. 3 Versuche).
Finale Architektur: 7 Agents
Sieben Agents, sechs Schritte:
- commit-analyzer: Scannt Commits, identifiziert geänderte Komponenten.
- test-planner.
- test-writer.
- test-validator.
- test-reviewer.
- mutation-planner + test-verifier.
Modellverteilung:
| Aufgabe | Modell |
|--------|--------|
| Planung, Schreiben, Review, Mutationen | Opus (tiefe Analyse) |
| Validierung, Mutationsausführung | Sonnet (Mechanik) |
commit-analyzer integriert sich in Git-Flow: Analysiert Diffs von Hash bis HEAD, schlägt Tests interaktiv vor (approve/skip).
Wichtige Erkenntnisse
- Multi-Agents meistern Test-Migration in Stunden, nicht Monaten.
- Mutationen sichern echte Qualität: 100% Bug-Erkennung.
.test-pipeline.yaml-Konfig passt sich jedem Projekt an.- Opus für Kreativität, Sonnet für Routine – perfektes Speed/Qualitäts-Gleichgewicht.
- Commit-Integration hält Tests immer aktuell.
— Editorial Team
Noch keine Kommentare.