Rozwój kierowany testami z AI

Prosisz agenta o helper do liczenia rabatów. Oddaje kod, który wygląda poprawnie, demo przechodzi, scalasz zmiany. Dwa dni później dział finansowy zgłasza, że zamówienia z wygasłymi kuponami wciąż dostają rabat — AI napisało implementację i testy razem, więc testy weryfikowały tylko zachowanie, które samo wcześniej zakodowało. Testy napisane po kodzie najczęściej dowodzą jedynie, że kod robi to, co robi kod.

Rozwój kierowany testami odwraca tę kolejność. Najpierw piszesz testy, potwierdzasz, że nie przechodzą z właściwego powodu, a potem pozwalasz AI implementować pod cel, którego nie da się oszukać. Pętla red-green-refactor to dokładnie taki ciasny, weryfikowalny cykl, w jakim agenci są dobrzy — a krok “potwierdź czerwony” jest tym, co powstrzymuje AI przed pisaniem testów, które przechodzą, niczego nie sprawdzając.

Co z tego wyniesiesz

• Powtarzalną pętlę red-green-refactor, którą prowadzisz z agentem, zamiast wpisywać każdą linię
• Gotowe do wklejenia prompty, które przypinają AI do jednej fazy naraz (testy, potem kod, potem refaktoryzacja)
• Wariant pętli dla Cursor / Claude Code / Codex, włącznie z tym, jak pozwolić zestawowi testów działać bez nadzoru
• Tryby awaryjne, które po cichu psują TDD sterowane przez AI — i jak przyłapać AI na edytowaniu testów, by wymusić zielony wynik

Przepływ pracy

Klasyczny cykl to “czerwony, zielony, refaktor”. Z agentem każda faza staje się osobną, wąską instrukcją. Dyscyplina, dzięki której to działa: nigdy nie pozwól, by ta sama tura napisała jednocześnie nieprzechodzący test i kod, który go zaspokaja.

1. Napisz testy (czerwony). Określ zachowanie i przypadki brzegowe oraz wyraźnie zabroń implementacji. Opisujesz kontrakt, a nie prosisz o funkcję.

2. Potwierdź niepowodzenie (czerwony). Niech agent uruchomi zestaw i pokaże ci niepowodzenia. To dowodzi, że testy celują w prawdziwe, niezaimplementowane zachowanie — a nie w literówkę w imporcie, która “nie przechodzi” z niewłaściwego powodu.

3. Implementuj do przejścia (zielony). Teraz daj jedną wąską instrukcję: spraw, by te testy przeszły, nie dotykaj plików testowych. Cel jest jednoznaczny i sprawdzalny maszynowo.

4. Iteruj i refaktoryzuj. Agent uruchamia zestaw, czyta niepowodzenia i poprawia, aż będzie zielono. Gdy jest zielono, poproś o przebieg refaktoryzacji — testy są teraz twoją siatką bezpieczeństwa.

Przykład z życia: reguła rabatu z prawdziwymi przypadkami brzegowymi

Zacznij od celowo małego pierwszego podejścia, żeby zobaczyć pętlę, a potem od razu przejdź do przypadku w kształcie produkcyjnym — metoda serwisowa ze ścieżkami błędów i zamockowaną zależnością, a nie czysta funkcja w izolacji.

Faza 1 — tylko testy. Przypnij model do pisania testów i niczego więcej:

Wskazówka

Prompt do wklejenia dla fazy czerwonej:

Write a comprehensive suite of Vitest tests for a PricingService.applyCoupon(cart, code) method in src/services/pricing.test.ts. cart is { items: { price: number; quantity: number }[] }; code is a string. Cover: correct subtotal, empty cart returns 0, a valid SAVE10 code applies 10% off the subtotal, an unknown code throws InvalidCouponError, and an expired code (the service calls couponRepo.findActive(code) which returns null when expired) throws CouponExpiredError. Mock couponRepo with vi.fn(). Do NOT create src/services/pricing.ts or write any implementation yet — tests only.

Faza 2 — potwierdź czerwony. Nie pomijaj tego. Plik testowy importujący moduł, który jeszcze nie istnieje, powinien zawieść już przy rozwiązywaniu importu; test, który tu przechodzi, to test niczego nie sprawdzający.

Wskazówka

Prompt do wklejenia, by potwierdzić niepowodzenie:

Run npx vitest run src/services/pricing.test.ts and show me the output. I expect every test to fail because PricingService does not exist yet. Confirm the failures are about the missing implementation, not a typo in the test file.

Faza 3 — implementuj do zielonego. Dopiero teraz autoryzujesz implementację i odgradzasz testy:

Wskazówka

Prompt do wklejenia dla fazy zielonej:

Implement PricingService in src/services/pricing.ts so every test in src/services/pricing.test.ts passes. Inject couponRepo through the constructor. Define InvalidCouponError and CouponExpiredError. Run the suite after each change and keep iterating until all tests are green. Do not modify any file under *.test.ts — if a test looks wrong, stop and tell me instead of changing it.

To ostatnie zdanie jest kluczowe. Bez niego agent, który utknie, często “naprawi” nieprzechodzącą asercję, zamiast poprawić kod.

Faza 4 — refaktoryzacja pod zielonym. Gdy zestaw przechodzi, masz kontrakt, który pozwala bezpiecznie przebudować kod:

Wskazówka

Prompt do wklejenia dla refaktoryzacji:

The suite is green. Refactor PricingService for readability: extract the discount lookup into a private method, add JSDoc to the public method, and prefer early returns over nested conditionals. Re-run npx vitest run after the refactor and confirm all tests still pass. Change implementation only — not tests.

Prowadzenie pętli w każdym narzędziu

Fazy są wszędzie identyczne; różni się to, jak każde narzędzie uruchamia zestaw i ile pętli test-napraw-przetestuj wykona bez nadzoru.

Cursor

Użyj trybu Agent i pozwól mu samodzielnie uruchamiać testy. W Settings -> Cursor Settings -> Agents -> Auto-Run ustaw Auto-Run Mode na Run in Sandbox (na macOS/Linux), aby polecenia wykonywały się automatycznie w piaskownicy bez pytania — to ścieżka pracy bez nadzoru, którą zaleca Cursor. Następnie dodaj npx vitest (lub npm test) do Command Allowlist, by runner testów uruchamiał się natychmiast nawet poza piaskownicą. Unikaj trybu Run Everything w pętli bez nadzoru: własne wskazówki dotyczące bezpieczeństwa Cursor mówią, by nigdy go nie używać, ponieważ pomija on wszystkie zabezpieczenia. Trzymaj fazy jako osobne tury czatu — punkty kontrolne Cursor pozwalają cofnąć się do “czerwonego”, jeśli przebieg zielonej fazy pójdzie nie tak. Obserwuj widok diff: jeśli edycja z fazy zielonej dotyka pliku *.test.ts, odrzuć ją.

Claude Code

Prowadź go z REPL albo skryptuj bezgłowo. Interaktywnie wklejaj kolejno każdy prompt fazy i pozwól Claude uruchamiać npm test. Aby pętla sama się korygowała, dodaj hook PostToolUse (matcher Edit|Write) w .claude/settings.json, który po każdej edycji ponownie uruchamia zestaw, dzięki czemu Claude od razu widzi niepowodzenia:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "npx vitest run --reporter=dot" }]
      }
    ]
  }
}

Dla jednorazowej fazy zielonej w CI lub w skrypcie uruchom go bezgłowo:

claude -p "Implement src/services/pricing.ts so the suite passes. Run 'npx vitest run' and iterate until green. Do not edit any *.test.ts file." --allowedTools "Read,Edit,Write,Bash"

Codex

W TUI uruchom fazę zieloną z --full-auto (ustawia piaskownicę workspace-write i zatwierdzenia on-request), by Codex mógł uruchamiać polecenie testowe i iterować bez pytania na każdym kroku:

codex --full-auto "Implement src/services/pricing.ts to pass tests in src/services/pricing.test.ts. Run 'npx vitest run' and iterate until green. Don't touch the test files."

Jeśli chcesz pytania tylko wtedy, gdy coś faktycznie zawiedzie, użyj zamiast tego codex --ask-for-approval on-failure. Do równoległych eksperymentów red/green — powiedzmy próbowania dwóch różnych implementacji wobec tych samych zablokowanych testów — uruchom każdy w osobnym worktree gita, by zestawy się nie kolidowały.

Notatka

Sięgnij po Claude Fable 5 (/model fable), gdy implementacja obejmuje złożoną logikę domenową, kilka wzajemnie oddziałujących przypadków brzegowych lub rozbudowaną fazę zieloną, którą chcesz rozwiązać w jednym przebiegu — to najbardziej zaawansowany model Anthropic, który wyraźnie przewyższa Opus 4.8 w trudnych refaktoryzacjach i pracy wieloplikowej. Claude Opus 4.8 to solidny środkowy wybór do większości logiki domenowej. Claude Sonnet 4.6 to tańszy domyślny wybór do rutynowego rusztowania i małych czystych funkcji. W Cursor selektor modelu sprawia, że przełączanie w trakcie pętli jest banalne — zacznij mocno w fazie zielonej, zejdź niżej do refaktoryzacji. Zobacz porównanie modeli po szczegóły cenowe i zestawienie kompromisów.

Kiedy to się psuje

Uwaga

AI edytuje testy, by wymusić zielony. Najczęstsza awaria: utknąwszy na trudnym przypadku, agent po cichu rozluźnia asercję lub ją usuwa, żeby zestaw przeszedł. Zawsze kończ prompt fazy zielonej słowami “do not modify any test file” i porównaj diff plików testowych, zanim zaufasz zielonemu przebiegowi. Przechodzący zestaw, który się skurczył, to sygnał ostrzegawczy.

Testy przechodzą, zanim kod istnieje. Jeśli “potwierdź czerwony” wraca na zielono, twoje testy w rzeczywistości nie ćwiczą celu — zwykle zamockowana zależność zwraca prawdziwą wartość domyślną albo import rozwiązuje się do zaślepki. Nigdy nie pomijaj kroku potwierdzania czerwonego.

Niestabilne testy asynchroniczne “naprawiane” przez sleep. Gdy testy zależne od czasu zawodzą sporadycznie, agenci uwielbiają zamaskować to przez setTimeout/sleep. Zamiast tego promptuj o deterministyczną kontrolę: “use fake timers (vi.useFakeTimers()) and advance them explicitly; do not add real delays.”

Zestaw jest zbyt wolny, by go zapętlać. Jeśli pełny zestaw trwa minuty, faza iteracji ślimaczy się. Podczas pętli zawęź runner do pliku poddawanego testom (npx vitest run src/services/pricing.test.ts), a na końcu uruchom cały zestaw raz.

Co dalej

Rozwój kierowany zachowaniem Przenieś tę samą ideę na poziom scenariuszy: prowadź agenta ze specyfikacji Given/When/Then.

Rozwój kierowany błędami Gdy sygnałem niepowodzenia jest błąd produkcyjny, a nie test, prowadź agenta z niego.

Testy jednostkowe z AI Głębsze wzorce mockowania, fixture'ów i pokrycia, gdy pętla red-green wejdzie w nawyk.