Programowanie sterowane testami z pomoca AI

Prosisz AI o zbudowanie rate limitera. Generuje cos, co wyglada poprawnie. Wdrazasz to. Dwa dni pozniej twoje API pada, bo rate limiter nie obsluguje poprawnie wspolbieznych zadan — wyścig warunkow, ktorego AI nigdy nie pomyslalo testowac, bo nigdy mu nie powiedziales, co oznacza “dzialajacy”.

TDD odwraca te dynamike. Gdy piszesz testy pierwsze, AI ma precyzyjna, maszynowo weryfikowalna definicje sukcesu. Nie musi zgadywac, czego chcesz. Uruchamia testy, widzi niepowodzenia i iteruje, az przejda. To pojedyncza technika o najwyzszej dzwigni do uzyskiwania niezawodnych wynikow od asystentow AI do kodowania.

Czego sie nauczysz

• Przeplyw pracy do pisania specyfikacji testow jako pierwszych i pozwalania AI implementowac na ich podstawie
• Prompty do generowania kompleksowych przypadkow testowych z wymagan
• Strategie radzenia sobie z tendencja AI do oslabienia asercji, zeby testy przechodzily
• Jasne zrozumienie, kiedy TDD z AI oszczedza czas, a kiedy dodaje narzut

Petla sprzezenia zwrotnego TDD-AI

Tradycyjne TDD podąza za cyklem czerwone-zielone-refaktoryzacja. Z AI ten cykl staje sie dramatycznie szybszy, poniewaz AI obsluguje fazy zielona i refaktoryzacji, a ty skupiasz sie na pisaniu sensownych czerwonych testow.

1. Piszesz test, ktory nie przechodzi, uchwycajacy oczekiwane zachowanie
2. AI pisze kod, ktory sprawia, ze test przechodzi
3. AI refaktoryzuje implementacje, utrzymujac testy na zielono
4. Przegladasz implementacje i piszesz nastepny test

Kluczowe spostrzezenie: test jest twoja specyfikacja. Dobrze napisany test komunikuje zamiar znacznie precyzyjniej niz jakikolwiek prompt w jezyku naturalnym.

Pisanie testow jako pierwszych

Zacznij od zdefiniowania zachowania, ktore chcesz, a nie implementacji. Mozesz napisac test samodzielnie lub wspolpracowac z AI przy generowaniu przypadkow testowych z wymagan — ale musisz przejrzec i zatwierdzic testy, zanim poprosisz o implementacje.

Cursor

Otworz tryb Agent. Popros Cursor o pomoc w wygenerowaniu przypadkow testowych, a nastepnie przejrzyj je przed poproszeniem o implementacje:

I need to build a rate limiter middleware for our Express API.
Requirements:
- 100 requests per minute per API key
- Returns 429 with a Retry-After header when exceeded
- Tracks limits in Redis
- Handles concurrent requests correctly

Write the test file first at src/middleware/__tests__/rateLimiter.test.ts.
Use our existing test patterns from @src/middleware/__tests__/auth.test.ts.
Do NOT write the implementation yet.

Przejrzyj testy. Dodaj przypadki brzegowe, ktore AI pominelo. Nastepnie:

Good tests. Now implement src/middleware/rateLimiter.ts to make
all tests pass. Run the tests after implementation and fix any
failures.

Cursor uruchomi testy w zintegrowanym terminalu, zobaczy niepowodzenia i bedzie iterowal, az wszystkie przejda.

Claude Code

Uzyj Plan Mode do wygenerowania specyfikacji testow, a nastepnie przelacz na Normal Mode do implementacji:

I need a rate limiter middleware. Requirements:
- 100 requests/minute per API key
- 429 response with Retry-After header when exceeded
- Redis-backed tracking
- Thread-safe under concurrent requests

Write comprehensive tests at src/middleware/__tests__/rateLimiter.test.ts.
Follow existing test patterns in the codebase. Do not implement yet.

Po przejrzeniu i zatwierdzeniu testow:

Implement src/middleware/rateLimiter.ts to pass all the tests.
Run npm test -- --testPathPattern=rateLimiter after each change
until all tests pass. Address root causes, not symptoms.

Agentyczna petla Claude Code uruchomi testy, przeczyta wyjscie, naprawi problemy i automatycznie ponownie uruchomi. To wlasnie w tej petli TDD z AI naprawde się sprawdza.

Codex

Popros Codex o wygenerowanie pliku testow jako pierwszego. Codex weryfikuje wlasna prace, uruchamiajac testy w swoim sandboxie:

Write tests for a rate limiter middleware at
src/middleware/__tests__/rateLimiter.test.ts.

Requirements:
- 100 requests/minute per API key
- 429 + Retry-After header when exceeded
- Redis-backed
- Handles concurrent requests safely

Follow existing test patterns in the codebase. Do not implement yet.

Po przejrzeniu rozpocznij nowy watek do implementacji:

Implement src/middleware/rateLimiter.ts to pass all tests in
src/middleware/__tests__/rateLimiter.test.ts.
Run the test suite and iterate until all tests pass.

Uzywanie oddzielnych watkow utrzymuje czysty kontekst. Watek implementacji skupia sie wylacznie na osiagnieciu zielonego stanu testow, bez rozmowy o generowaniu testow zasmiecajacej kontekst.

Gotowy prompt: Generowanie przypadkow testowych z wymagan

I need to implement [FEATURE]. Here are the requirements:
[paste requirements]

Write comprehensive tests FIRST at [test file path]. Cover:
1. Happy path for each requirement
2. Edge cases (empty input, boundary values, concurrent access)
3. Error cases (invalid input, missing dependencies, timeouts)
4. Integration with existing code (follow patterns in @[existing test file])

Do NOT write the implementation. I will review the tests before we proceed.

Kierowanie faza implementacji

Gdy testy sa na miejscu, faza implementacji to miejsce, gdzie AI dostarcza najwieksza wartosc. Testy dzialaja jako ciagly sygnal sprzezenia zwrotnego, ktory utrzymuje AI na wlasciwym torze.

Cursor

Odwolaj sie zarowno do pliku testow, jak i do odpowiedniego istniejacego kodu:

Implement the rate limiter to pass @src/middleware/__tests__/rateLimiter.test.ts.
Reference @src/middleware/auth.ts for our middleware patterns.
Run the tests after each significant change.
If a test fails, read the error carefully and fix the root cause.

Uzyj checkpointow Cursor do zrobienia migawki znanych dobrych stanow. Jesli AI zepsuje cos, co przechodzilo, cofnij do checkpointu zamiast debugowac do przodu.

Claude Code

Daj Claude jasna dyrektywe implementacji z weryfikacja:

Implement rateLimiter.ts to pass all tests. After implementation:
1. Run npm test -- --testPathPattern=rateLimiter
2. If any test fails, read the full error output
3. Fix the root cause (don't modify the tests)
4. Re-run until all tests pass
5. Then run the full test suite to check for regressions

Jesli Claude utknie w petli nieudanych testow, uzyj /clear i rozpocznij nowa sesje z bardziej precyzyjnym promptem opisujacym konkretne niepowodzenie.

Codex

Sandbox Codex automatycznie uruchamia weryfikacje:

Implement src/middleware/rateLimiter.ts to pass all existing tests.
Follow the middleware pattern from src/middleware/auth.ts.
Run the test suite after implementation. Do not modify test files.
If tests fail, fix the implementation, not the tests.

W aplikacji Codex mozesz obserwowac implementacje w czasie rzeczywistym i widziec wyniki testow, gdy Codex iteruje.

Gotowy prompt: Implementacja z weryfikacja testami

Implement [file path] to make all tests in [test file path] pass.

Rules:
- Do NOT modify the test files
- Run the tests after each significant change
- If a test fails, fix the implementation, not the test
- After all tests pass, run the full test suite to check for regressions
- Follow existing patterns in @[reference implementation file]

Wychwytywanie antywzorca “oslabiania testow”

Najbardziej niebezpieczny tryb awarii w TDD wspomaganym AI to sytuacja, gdy AI modyfikuje twoje testy, zeby przechodzily, zamiast naprawiac implementacje. Zwracaj uwage na te znaki:

• Asercje staja sie mniej konkretne. expect(result).toBe(429) staje sie expect(result).toBeDefined().
• Testy sa usuwane. AI usuwa “niestabilne” testy zamiast naprawiac kod.
• Mocki zastepuja prawdziwe zachowanie. AI mockuje dokladnie to, co chciałes przetestowac.

Chron swoje testy

Zawsze dodawaj “Do NOT modify the test files” w swoich promptach implementacji. W Claude Code mozesz to wymusic hookiem blokujacym zapisy do plikow testowych podczas implementacji. W Cursor dodaj regule projektu w .cursor/rules/tdd.md, ktora mowi “Never modify test files during implementation tasks.” W Codex dodaj to do swojego AGENTS.md.

Gotowy prompt: Dodawanie testow przypadkow brzegowych po implementacji

The implementation passes all current tests. Now let's strengthen coverage.

Review @[implementation file] and write additional tests for:
1. Race conditions (parallel calls with the same input)
2. Boundary values (exactly at the limit, one over, one under)
3. Failure recovery (what happens when Redis goes down mid-request?)
4. Memory/resource cleanup (are connections properly released?)

Add these tests to @[test file]. Then run them -- some SHOULD fail.
We'll fix the implementation next.

Kiedy to nie dziala

AI generuje trywialne testy. Jesli twoje prompty testowe sa ogolnikowe (“write tests for this function”), AI napisze testy weryfikujace, ze funkcja istnieje i cos zwraca. Badz konkretny w kwestii zachowan, ktore chcesz przetestowac. Dolacz konkretne przyklady wejsc i wyjsc.

Testy sa zbyt scisle powiazane z implementacja. Jesli twoje testy sprawdzaja wewnetrzne szczegoly implementacji (wywolania prywatnych metod, konkretne struktury danych), AI nie moze swobodnie refaktoryzowac. Pisz testy pod publiczne API i oczekiwane zachowania, nie wewnetrzna mechanike.

Zestaw testow jest zbyt wolny. TDD wspomagane AI dziala najlepiej, gdy testy uruchamiaja sie w sekundach. Jesli pelny zestaw testow trwa 10 minut, AI nie bedzie efektywnie iterowal. Uzyj --testPathPattern lub --grep, aby uruchamiac tylko odpowiednie testy podczas rozwoju.

Piszesz zbyt wiele testow z gory. Zacznij od 3-5 testow pokrywajacych podstawowe zachowanie. Pozwol implementacji ujawnic, ktore przypadki brzegowe sa wazne, a nastepnie dodawaj wiecej testow iteracyjnie. Probowanie napisania 30 testow przed jakakolwiek implementacja prowadzi do paralizy analitycznego.

Co dalej

Programowanie sterowane bledami Gdy testy ujawniaja nieoczekiwane niepowodzenia, uzyj ich jako sygnalu do nauki zamiast z nimi walczyc.

Od PRD przez plan do listy zadan Polacz TDD z ustrukturyzowanym planowaniem dla maksymalnej niezawodnosci.

Tryb agenta vs tryb zapytan Dowiedz sie, kiedy pozwolic AI uruchamiac testy autonomicznie, a kiedy przechodzic reczenie.