Testowanie i debugowanie z Claude Code

Testowanie i debugowanie z Claude Code działa wtedy, gdy o tym, co znaczy „gotowe”, decydują testy, a nie model: polecenia testowe są w CLAUDE.md, hooki uruchamiają testy po każdej edycji, sesja implementująca nie może zmieniać plików testów, a każda poprawka błędu zaczyna się od testu, który pada z rozpoznanej przyczyny. Tryb planowania ogranicza diagnozę do odczytu.

Ten hub jest dla programistów, którzy zlecają Claude Code pisanie testów i poprawek, oraz dla tech leadów, którzy decydują, czego takie pull requesty muszą dowieść. Znasz ten scenariusz: Claude melduje „wszystkie testy przechodzą”, pokrycie rośnie, a błąd i tak trafia na produkcję, bo nowe testy sprawdzały tylko, czy wywołano mocki, albo asercję po cichu poluzowano. Polecenia sprawdzono na Claude Code v2.1.283 (kanał latest).

Która strona o testach w Claude Code odpowiada na twoje pytanie?

Twoje pytanie	Strona
Jak dostać testy zgodne z naszymi wzorcami, prowadzić red-green-refactor i łapać prawdziwe błędy?	Generowanie testów i TDD z Claude Code
Coś jest zepsute. Jak znaleźć przyczynę źródłową zamiast łatać objaw?	Debugowanie z Claude Code w terminalu
Jak mocny musi być zestaw testów, żebym ufał testom, których nie czytałem?	Jak silna jest twoja wyrocznia?
Jak powstrzymać agenta przed edytowaniem kontroli, które go oceniają?	Ochrona wyroczni
Źle działa sam Claude Code: zawiesza się, zapętla na uprawnieniach, gubi kontekst	Rozwiązywanie problemów z Claude Code

Praktyki testowe wspólne dla wszystkich agentów opisuje testowanie we wszystkich narzędziach.

W jakiej kolejności skonfigurować testowanie z Claude Code?

Każdy krok usuwa jeden sposób, w jaki zielony wynik może kłamać. Zrób je raz na repozytorium.

1. Wpisz polecenia testowe do CLAUDE.md. Podaj polecenie dla jednego pliku, dla testów powiązanych i dla całego zestawu, a do tego regułę „nigdy nie edytuj testu, żeby przeszedł”. Claude użyje ich, zamiast zgadywać.

2. Dodaj hooki informacji zwrotnej. Hook PostToolUse z matcherem Edit|Write uruchamia powiązane testy po każdej edycji, a hook Stop uruchamia szybki zestaw, zanim Claude zgłosi koniec. Oba przy błędzie kończą się kodem wyjścia 2, co odsyła do Claude stderr hooka, więc przekieruj wyjście runnera przez 1>&2. Skrypty i blok ustawień znajdziesz w generowaniu testów i TDD, a pozostałe zdarzenia w automatyzacji z hookami.

3. Zablokuj testy na czas implementacji. „Nie edytuj testu” w prompcie to prośba. Reguła "Edit(**/*.test.ts)" w permissions.deny (albo claude --disallowedTools "Edit(**/*.test.ts)") blokuje narzędzia plikowe i rozpoznawane zapisy z powłoki, takie jak sed czy >, ale nie skrypt, który sam otwiera pliki. Blokadą dla całej gałęzi jest kontrola CI leżąca poza diffem.

4. Diagnozuj tylko do odczytu. Od v2.1.283 (kanał latest) sesje interaktywne zwykle startują w trybie auto, w którym działania zatwierdza klasyfikator zamiast ciebie; claude -p i domyślne modele niektórych dostawców nadal startują w trybie Manual. Przy błędzie przełącz się na tryb planowania (claude --permission-mode plan, /plan albo Shift+Tab), żeby nic się nie zmieniło, dopóki Claude nie wskaże jednej przyczyny: pliku, linii i warunku.

5. Najpierw dowód, potem poprawka. Nowy test musi paść z rozpoznanej przyczyny, zanim powstanie jakakolwiek poprawka. Jeśli pada z innego powodu, diagnoza jest błędna.

Prompt do skopiowania: czy ten zestaw testów zasługuje na zaufanie?

Audit src/services/order.service.ts and src/services/order.service.test.ts.
Never edit the test file. Stop and tell me if `git status` shows either
file already modified.
1. List every behaviour the tests assert, one line each, and every public
   function, thrown error and catch branch that no test exercises.
2. Pick five lines in the service where a plausible bug could hide
   (an off-by-one, a flipped condition, a missing await, a swallowed error).
   For each one: apply that single mutation to the service, run
   `npx vitest run src/services/order.service.test.ts`, record whether the
   suite went red, then restore the file with
   `git checkout -- src/services/order.service.ts`.
3. Report a table: mutation, file:line, caught (yes/no). For every
   surviving mutation, name the test that is missing.
Finish with `git status` to show the working tree is clean.

Prompt do skopiowania: przekaż awarię, nie zapraszając do łatania

CI fails on this branch. The failing job output is below.
Stay read-only. Read the failing test and every file in the stack trace.
Tell me whether this is (a) a bug in the code, (b) a wrong or flaky test,
or (c) an environment difference between CI and local, and give the one
piece of evidence that decides it. Then propose a new test that fails for
exactly the reason you name. Do not write the fix.

Skąd wiesz, że testy i poprawki od Claude Code są dobre, bez czytania każdej linii?

Czytaj dowody, a diff otwieraj tylko tam, gdzie dowody wskazują.

Dowód	Czego dowodzi	Właściciel
Lista nazw testów zatwierdzona przed generowaniem	Zestaw pokrywa zachowania, na których ci zależy	Programista
Nowy test był czerwony z podanej przyczyny, zanim powstała poprawka	Test wykrywa błąd, który ma wykrywać	Programista (na podstawie wyniku hooka)
Pliki testów bez zmian w diffie poprawki	Nikt nie uzyskał zielonych testów, osłabiając je	Kontrola CI na ścieżkach testów
Lista mutantów, które przeżyły, przejrzana i rozstrzygnięta	Zestaw łapie wstrzyknięte błędy, a nie tylko dzisiejszy kod	Recenzent
Pełny zestaw testów, typy i lint zielone w CI	Dotychczasowe zachowanie działa, poza kontrolą agenta	CI

Co pull request dołącza jako dowód, definiuje pakiet dowodów, a dlaczego czytasz dowody zamiast diffu, wyjaśnia czytanie dowodów zamiast kodu. Nawyk naprawiania przez test, na którym opiera się ta tabela, opisuje naprawianie sterowane testami.

Co się psuje, gdy Claude Code testuje i debuguje własną pracę?

Objaw	Przyczyna	Jak wyjść
Testy zielone, błąd na produkcji	Testy sprawdzają mocki, a nie zachowanie	Dodaj test integracyjny na styku z usługą; uruchom powyższy prompt mutacyjny
Poprawka przechodzi dzięki zmianie asercji	Pliki testów były edytowalne w trakcie poprawki	Dodaj regułę permissions.deny i kontrolę CI, która pada, gdy ścieżki testów zmieniają się bez zgody właściciela
Ta sama awaria wraca z innego miejsca wywołania	Claude załatał objaw sprawdzeniem na null	Wróć do trybu planowania; zapytaj, gdzie powstaje zła wartość i które wywołania mają to samo założenie
Tury kończą się powoli albo Claude krąży wokół czerwonego zestawu	Hook Stop uruchamia wolny lub niestabilny zestaw	Skieruj go na szybkie testy jednostkowe; wolne zestawy zostaw CI
Pliki snapshotów zmieniają się w poprawce, choć testy są zablokowane	Nadpisał je vitest -u albo skrypt; reguły deny nie obejmują podprocesów, które same otwierają pliki	Przywróć snapshoty, dodaj "Bash(npx vitest * -u*)" i "Bash(npx vitest * --update*)" do permissions.deny (inne zapisy, np. pnpm vitest albo npm test -- -u, wymagają własnych reguł) i włącz __snapshots__/ do kontroli ścieżek testów w CI, która jest właściwą blokadą
Diagnoza brzmi sensownie, ale nowy test pada z innego powodu	Dwie prawdopodobne przyczyny nigdy nie zostały rozdzielone	Uznaj diagnozę za obaloną; poproś Claude o dowód, który wyklucza każdą z przyczyn

Dokąd dalej z testowaniem i debugowaniem w Claude Code

Testy, które łapią błędy

Generowanie testów i TDD z Claude Code

Znajdź przyczynę źródłową

Debugowanie z Claude Code w terminalu

Wdróż to, czego dowiodły testy

Code review i wdrożenie z Claude Code

Skille i pluginy do testów

Skille do testowania i debugowania

Testowany kod powstaje na etapie budowania z Claude Code. Pracujesz też z innym agentem? Ten sam etap opisują testowanie i debugowanie z Codexem oraz testowanie i debugowanie z Cursorem.