Testowanie i weryfikacja kodu pisanego przez agentów

Weryfikacja kodu pisanego przez agentów polega na zbudowaniu sprawdzeń na tyle silnych, że zielonemu przebiegowi można zaufać bez czytania każdej linii przez człowieka.

Agent otwiera pull request: 600 zmienionych linii i 40 nowych testów, wszystko na zielono. Przeczytanie całości zajmie popołudnie; scalenie po zielonym checku CI to zaufanie testom napisanym przez agenta, który miał sprawić, żeby przeszły. Ta sekcja jest dla developerów i tech leadów, którzy chcą trzeciej drogi: sprawić, żeby sprawdzeniom dało się ufać, a potem oceniać dowody zamiast diffu.

Od której strony o testach zacząć?

Czytaj od góry: mocny zestaw testów, który agent może edytować, niczego nie dowodzi.

Twoje pytanie	Strona	Dlaczego właśnie tutaj
Czy te testy w ogóle łapią błędy?	Siła wyroczni	Poprzeczka, na której opiera się reszta.
Czy agent może zmienić testy, żeby przeszły?	Ochrona wyroczni	Trzyma decydujące sprawdzenia poza zasięgiem agenta.
Jakie testy agent ma pisać na każdej warstwie?	Jednostkowe, integracyjne, API, end-to-end	Testy z kryteriów akceptacji, a nie z kodu.
Czy działa uruchomiona aplikacja, a nie tylko kod?	Weryfikacja w przeglądarce przez agenta	Zrzuty ekranu i ślady jako dowód.
Czy sam agent działa tak samo po zmianie modelu albo promptu?	Ciągłe ewaluacje	Testy regresyjne harnessu agenta uruchamiane w CI.
Co z zachowaniem, którego nie da się uchwycić przykładami?	Testy właściwości, ocena przez model	Niezmienniki, których agent nie obejdzie, i sędziowie oceniający teksty i wygląd według rubryki.
Działa, ale czy zostanie utrzymywalne i bezpieczne?	Funkcje dopasowania, wykrywanie slopu, kontrola zależności, bramki jakości	Bramki jakości na erozję, kod wiarygodny, ale błędny, i zmyślone pakiety.
Kod nie ma jeszcze testów.	Testy charakteryzacyjne	Utrwal dzisiejsze zachowanie, zanim agent zacznie refaktoryzować.
Czy potrzebuję specjalistycznej bramki jakości?	Dostępność, wydajność, bezpieczeństwo, wstrzykiwanie błędów, aplikacje mobilne, dane testowe	Dodaj, gdy wymaga tego produkt.

Zacznij od audytu wyroczni w jednym module

Wybierz moduł, który agent zmienia najczęściej. Pierwszy prompt mierzy, co łapią jego testy, i niczego nie zmienia.

Prompt do skopiowania: audyt, jak dobrze testy łapią błędy

Audit the tests for src/billing/ and report how well they catch bugs. Do not edit source, test or config files; tool reports and temp directories are fine.

1. Run the repository's mutation testing tool on src/billing/ only
   (Stryker for JS/TS, mutmut for Python, cargo-mutants for Rust). If none is
   configured, say so and propose the minimal config instead of installing it.
2. Report the mutation score and list every surviving mutant as file:line,
   what was changed, and which behaviour a test should have asserted.
3. List tests that assert nothing meaningful: no assertion, assertions on mocks
   only, or snapshots nobody could review.
4. Report flaky tests: run the suite three times and list any test whose result changes.
Finish with a table: behaviour, test that covers it (or "none"), confidence.

Jeśli narzędzie mutacyjne nie jest skonfigurowane, instalacja to npm i -D @stryker-mutator/core (Stryker 10.0.0), pip install mutmut (mutmut 3.8.0) albo cargo install cargo-mutants (cargo-mutants 27.1.0); konfigurację opisuje strona siła wyroczni.

Drugi prompt pisze czerwone testy na podstawie wykonywalnych kryteriów akceptacji przed implementacją.

Prompt do skopiowania: najpierw czerwone testy z kryteriów akceptacji

Read the acceptance criteria in specs/refund-limits.md. Before writing any
implementation code:

1. Write one test per criterion under tests/refunds/, named after the criterion.
   Assert on observable behaviour (return values, persisted state, emitted events),
   not on internal calls.
2. Run them and show that every new test fails for the expected reason.
   A test that passes now is testing nothing: rewrite it.
3. Stop and show me the criterion-to-test mapping and the failing output.

Do not modify existing tests. If an existing test conflicts with a criterion,
report the conflict instead of changing the test.

Zapisz pierwszy prompt jako prompts/oracle-audit.md; polecenia bez interakcji poniżej czytają go z tego pliku. Prompty są takie same w każdym narzędziu; różni się sposób ich uruchamiania.

Claude Code

Wklej prompt do interaktywnej sesji claude albo uruchom go bez interakcji. claude -p startuje w trybie uprawnień Manual (od v2.1.285 w trybie auto u zewnętrznych dostawców lub z wyłączoną telemetrią, gdzie decyduje klasyfikator), więc dodaj --permission-mode dontAsk, żeby u każdego dostawcy odrzucać wywołania Bash, o które nie może zapytać, i jawnie zezwól na polecenia testów i mutacji (tu dla projektu JS/TS): claude -p "$(cat prompts/oracle-audit.md)" --permission-mode dontAsk --allowedTools "Bash(npx stryker *)" "Bash(npm test *)" (flagi: 2.1.283; zmiana z v2.1.285: changelog Claude Code, sprawdzone 2026-10-12). Przy prompcie z czerwonymi testami, który zapisuje pliki, przekaż zamiast tego --permission-mode acceptEdits. Żeby agent nie edytował testów przy drugim prompcie, dodaj reguły deny dla ścieżek testowych, jak na stronie ochrona wyroczni. Szczegóły konfiguracji w tym narzędziu: testowanie z Claude Code.

Codex

Wklej prompt do interaktywnej sesji codex albo uruchom go bez interakcji: codex exec --sandbox workspace-write "$(cat prompts/oracle-audit.md)"; narzędzia mutacyjne zapisują pliki tymczasowe i raporty, więc w sandboksie tylko do odczytu padną. Sprawdzone na Codex CLI 0.157.1. Szczegóły konfiguracji w tym narzędziu: testowanie z Codeksem.

Cursor

Wklej prompt do czatu Agenta albo uruchom go bez interakcji w trybie print Cursor CLI (-p, --print), który działa też w GitHub Actions. Cursor nie ma wbudowanej reguły deny dla ścieżek testowych; hook może blokować takie edycje (ochrona wyroczni), ale miejscem egzekwowania jest CI: CODEOWNERS na ścieżkach testowych i wymagany check. Szczegóły konfiguracji w tym narzędziu: wzorce testowania w Cursorze.

Skąd wiesz, że testom można ufać, skoro ich nie czytasz?

Cztery sygnały zastępują czytanie każdego testu.

Sygnał	Wystarczy, gdy	Kto odpowiada
Wynik mutacyjny na zmienionym kodzie	Przeżyte mutanty są wypisane, a każdy jest zabity albo wyjaśniony	Developer, który uruchamia agenta
Mapa kryterium → test	Każde kryterium akceptacji ma test z zapisanym czerwonym przebiegiem	Developer; recenzent sprawdza wyrywkowo
Ochrona wyroczni	Zmiana testów i konfiguracji CI wymaga zgody właściciela kodu	Tech lead
Odsetek niestabilnych testów	Niestabilne testy trafiają do kwarantanny, a nie są ponawiane do skutku	Tech lead

Te sygnały trafiają do pull requesta jako pakiet dowodów, a recenzent zatwierdza pakiet. Uzasadnienie takiego sposobu pracy znajdziesz w tekście czytanie dowodów zamiast kodu.

Co się psuje, gdy agenci piszą własne testy?

Zestaw jest zielony, a błędy i tak trafiają na produkcję. Testy sprawdzają szczegóły implementacji albo mocki. Jak naprawić: uruchom prompt audytowy, a potem każ agentowi zabić każdego przeżytego mutanta asercją na zachowaniu.

Agent poluzował test, żeby przeszedł. W ramach „poprawki” toBe(19.99) zmieniło się w toBeCloseTo(20, 0). Jak naprawić: cofnij zmianę w teście i schowaj ścieżki testowe za regułami deny i CODEOWNERS.

Próg pokrycia stał się celem samym w sobie. Agenci goniący za procentem pokrycia dopisują testy wykonujące linie bez sprawdzania ich. Jak naprawić: zastąp próg pokrycia mapą kryterium → test i wynikiem mutacyjnym na zmienionym kodzie.

Po serii wygenerowanych testów zestaw zwolnił i stał się niestabilny. Jak naprawić: usuń testy, które nie zabijają żadnego mutanta pominiętego przez resztę zestawu, i przenieś do kwarantanny każdy test, którego wynik zmienia się między identycznymi przebiegami.

Dokąd iść po sekcji o testowaniu

Wykonywalne kryteria akceptacji Kryteria na tyle precyzyjne, że stają się czerwonymi testami.

Siła wyroczni Zmierz, co łapią twoje testy.

Pakiet dowodów Spakuj wyniki testów dla recenzenta.

Code review PR-a agenta Oceniaj pull requesty agenta na podstawie dowodów.