Naprawa sterowana testami — czerwony test najpierw i blokada pliku

Naprawa sterowana testami wymaga od agenta odtworzenia usterki czerwonym testem, zachowania zaakceptowanej reprodukcji i poprawienia kodu bez osłabiania testu. Ochrona testu ogranicza false green, lecz nie dowodzi kompletności reprodukcji; zachowanie i scope nadal musi zatwierdzić człowiek lub niezależne review.

Pytanie w scorecardzie: W jaki sposób podchodzisz do naprawiania błędów przez agentów AI (test-first fixing)? Maksymalna odpowiedź (3 pkt): Rygorystyczny protokół test-first: zacommitowany czerwony test, hook blokujący edycję testów w fazie naprawy, zweryfikowany zielony przebieg.

Dlaczego to ważne w 2026

Gdy programiści podają agentowi ślad stosu (stack trace) ze słowami „napraw ten błąd”, model bardzo często halucynuje sukces. Bez odtwarzalnego testu agent modyfikuje logikę aplikacji w sposób, który maskuje objawy lub psuje sąsiednie przepływy, jednocześnie deklarując rozwiązanie problemu. Co gorsza, proszony o napisanie testu równolegle z poprawką, agent nagminnie dostosowuje asercje testowe do swojej wadliwej implementacji.

Protokół test-first tworzy empiryczną barierę: agent musi dowieść istnienia defektu, pisząc czerwony test jednostkowy lub integracyjny. Po zacommitowaniu nieprzechodzącego testu agent otrzymuje zakaz modyfikacji plików testowych na etapie tworzenia poprawki. Jedynym akceptowalnym rezultatem są zmiany w kodzie produkcyjnym, które sprawią, że test przejdzie na zielono.

Jak wygląda maksymalny wynik

Przepływ z maksymalną oceną w Q15 obejmuje cztery rygorystyczne etapy:

1. Odtworzenie błędu: Agent pisze wyizolowany test odtwarzający błąd i uruchamia go, wykazując niezerowy kod wyjścia.
2. Zacommitowany czerwony stan: Nieprzechodzący test zostaje zacommitowany do gita jako dowód przed wprowadzeniem jakichkolwiek zmian w kodzie aplikacji.
3. Zablokowane pliki testowe: Hooki lub uprawnienia blokują agentowi możliwość edycji plików testowych w fazie naprawiania kodu.
4. Zweryfikowany zielony stan: Zestaw testów wykonuje się pomyślnie z zerem modyfikacji w zacommitowanym teście reprodukującym.

Wdrożenie krok po kroku

1. Zleć agentowi napisanie testu reprodukującego problem.

   Dostarcz raport o błędzie lub log błędu i zabroń modyfikacji kodu źródłowego:

   Claude Code

   Zgłoszenie błędu: Gdy użytkownik zmienia adres email, token sesji zostaje
   niespodziewanie unieważniony.
   Napisz test w tests/auth/email_change.test.ts odtwarzający ten błąd.
   Uruchom test i potwierdź, że nie przechodzi. Nie modyfikuj żadnych plików w src/.

   Cursor

   W trybie Agent poinstruuj:

   Odtwórz błąd #402 dodając nieprzechodzący test w tests/unit/payment.test.ts.
   Uruchom `npm test tests/unit/payment.test.ts` i potwierdź kod wyjścia 1.
   Nie dotykaj jeszcze katalogu src/.

   Codex

   Dodaj test integracyjny odtwarzający race condition opisany w INCIDENT_REPORT.
   Potwierdź, że test nie przechodzi pod poleceniem `pytest tests/test_concurrency.py`.
   Nie modyfikuj kodu aplikacji.

2. Zacommituj czerwony test.

   Zapisz test odtwarzający usterkę jako samodzielny commit:

   git add tests/auth/email_change.test.ts
   git commit -m "test: odtworzenie niespodziewanego uniewaznienia sesji przy zmianie emaila"

3. Wymuś blokadę plików testowych w trakcie naprawy.

   Zablokuj agentowi możliwość modyfikacji testów w celu wymuszenia zielonego wyniku. Użyj hooka pre-tool lub skryptu blokującego:

   # Przykład .claude/hooks/protect-tests.sh lub hook pre-commit w git
   #!/bin/bash
   # Blokuje edycje plikow testowych podczas naprawiania bledow
   changed_files=$(git diff --name-only)
   if [[ "$FIX_MODE" == "true" ]] && echo "$changed_files" | grep -q "^tests/"; then
     echo "Blad: Modyfikowanie plikow testowych w trakcie naprawy bledu jest zabronione." >&2
     exit 2
   fi

4. Zleć agentowi naprawę błędu w kodzie.

   Poinstruuj agenta, aby sprawił, by czerwony test przeszedł na zielono:

   Test odtwarzający błąd jest zacommitowany w tests/auth/email_change.test.ts.
   Napraw problem w src/auth/, aby test przeszedł na zielono.
   Nie edytuj tests/auth/email_change.test.ts. Uruchom zestaw testów, aby dowieść poprawności.

5. Zweryfikuj czysty zielony przebieg.

   Potwierdź, że test przeszedł, żadne inne testy nie uległy regresji, a diff dotyka wyłącznie plików aplikacji.

Częste pułapki

• Pisanie testu i poprawki jednocześnie: Pozwalanie agentowi na napisanie testu i kodu w jednym kroku. Model zazwyczaj napisze test potwierdzający jego własny, wadliwy kod.
• Osłabianie asercji (assertion dilution): Gdy agent natrafia na trudny przypadek brzegowy, łagodzi asercję (np. zamienia toBe(expected) na toBeTruthy()) zamiast naprawić logikę biznesową.
• Ignorowanie testów sąsiednich: Naprawienie nowego testu przy jednoczesnym popsuciu 3 istniejących. Zawsze wymagaj uruchomienia pełnego zestawu regresyjnego przed zakończeniem zadania.

Jak sprawdzić, czy już tam jesteś

• Pull requesty naprawiające błędy zawierają co najmniej dwa commity: pierwszy dodający czerwony test i kolejne wprowadzające naprawę.
• W diffach gita dla zadań naprawczych nigdy nie występują osłabione asercje w istniejących plikach testowych.
• Hooki automatycznie blokują edycję katalogu tests/**, gdy aktywny jest tryb naprawy.
• Liczba powracających błędów produkcyjnych spada, ponieważ testy reprodukujące na stałe wzbogacają zestaw regresyjny.

Dodatkowe materiały

Etap Test w natywnym dla AI SDLC Tworzenie pętli testowych, zestawów regresyjnych i ciągłych ewaluacji.

Q14 · Pętla feedbacku w sesji Jak budować samonaprawiające się pętle testowe dla agentów.

Q17 · Ciągłe ewaluacje w CI Zamieniaj incydenty produkcyjne w trwałe ewaluacje regresyjne.