System wieloagentowy dla automatyzacji testów jednostkowych React: od planowania do mutacji
Programiści projektów React często muszą migrować testy z Enzyme do React Testing Library (RTL). Ręczna przeprawa setek komponentów zajmuje miesiące. Automatyzacja poprzez LLM redukuje wysiłek: od prostych podpowiedzi do wieloagentowego pipeline'u z weryfikacją mutacji. System generuje, przegląda i sprawdza testy, integrując się z przepływem pracy.
Porażka naiwnych podejść
Początkowe eksperymenty z ChatGPT dawały niepracujący kod: błędy TypeScript, antywzorce RTL, brak kontekstu projektu. Model generował typowe testy bez uwzględnienia mocków, stanu i routingu.
Pipeline N8N z systematyczną podpowiedzią częściowo poprawił sytuację:
- Analiza komponentu i ocena złożoności.
- Klasyfikacja przypadków testowych (proste, średnie, złożone).
- Generowanie według grup z przykładami.
Ale bez uruchomienia w projekcie testy się nie kompilowały. Cursor z dostępem do plików IDE dał krok naprzód: widział importy i typy, ale wymagał powtarzania podpowiedzi z filozofią RTL.
Claude Code: baza dla agentów
Claude Code wprowadził agentów z osobnym kontekstem i dostępem do projektu. Agenci widzą pliki, uruchamiają polecenia (ESLint, TypeScript, Jest/Vitest). Umiejętność unit-tester koordynuje pipeline, tworząc subagentów.
Konfiguracja .test-pipeline.yaml przechowuje specyfiki projektowe: ścieżki mocków, stan, runner testów, reguły.
Prototyp z trzema agentami
Podstawowy pipeline:
- test-planner: analizuje komponent (UI vs kontener), planuje przypadki.
- test-writer: generuje
.test.tsxzgodnie z planem. - test-validator: sprawdza kompilację i uruchomienie (ESLint, TS, testy).
Zalety:
- Praca z pełnym projektem.
- Samoweryfikacja wyników.
- Skupienie agentów na zadaniach.
- Kontekst projektowy z konfiguracji.
Przegląd zgodnie z filozofią RTL
Zielone testy nie gwarantują jakości. Agent test-reviewer ocenia (1–10):
- Testowanie zachowania, a nie implementacji.
- Dostęp poprzez role/etykiety, bez klas CSS.
- Informacyjne opisy przypadków.
- Stałe zamiast ciągów znaków.
Przy ocenie <9 – poprawka (maks. 3 iteracje).
Mutacyjne testowanie dla weryfikacji
Kluczowy krok: upewnić się, że testy wykrywają błędy. mutation-planner generuje mutacje według przypadków:
- Blokowanie przycisku przy pustym emailu → usunąć
disabled. - Wyświetlanie błędu → usunąć renderowanie.
- Wywołanie API → zakomentować.
test-verifier wykonuje sekwencyjnie:
- Test przechodzi na oryginale ✅.
- Kopia zapasowa komponentu.
- Mutacja, test nie przechodzi ❌.
- Przywrócenie, test przechodzi ✅.
Cel: 100% wskaźnik wykrywania. Niżej – poprawka (maks. 3 próby).
Finalna architektura: 7 agentów
Siedem agentów, sześć kroków:
- commit-analyzer: skanuje commity, identyfikuje zmienione komponenty.
- test-planner.
- test-writer.
- test-validator.
- test-reviewer.
- mutation-planner + test-verifier.
Rozłożenie modeli:
| Zadanie | Model |
|--------|--------|
| Planowanie, pisanie, przegląd, mutacje | Opus (głęboka analiza) |
| Walidacja, wykonanie mutacji | Sonnet (mechanika) |
commit-analyzer integruje z Git-flow: analizuje diff od hasha do HEAD, proponuje testy interaktywnie (approve/skip).
Co jest ważne
- Wieloagenci rozwiązują zadanie migracji testów w godziny zamiast miesięcy.
- Mutacje zapewniają realną jakość: 100% detekcja błędów.
- Konfiguracja
.test-pipeline.yamladaptuje do projektów. - Opus dla kreatywności, Sonnet dla rutyny – równowaga szybkości/jakości.
- Integracja w commity automatyzuje wsparcie testów.
— Editorial Team
Brak komentarzy.