Generowanie i uruchamianie testów z Codexem

Generowanie testów z Codexem bezpiecznie domyka luki w pokryciu, gdy każdy moduł dostaje własny tor w osobnym worktree Git, tor może dodawać testy, ale nigdy nie zmienia kodu źródłowego, a wynik ocenia się po dowodach, nie po lekturze: bramka „tylko testy”, przyrost pokrycia na plik, wynik testów mutacyjnych i przebieg codex review przed merge’em.

Raport pokrycia pokazuje 34%, lista kontrolna wydania wymaga 80%, a 200 niepokrytych funkcji leży w 40 plikach. Możesz poprosić Codexa, żeby „dopisał testy, aż pokrycie dojdzie do 80%”, i zrobi to: testami, które sprawdzają, czy wywołano mocki, i przechodzą niezależnie od tego, co robi kod. Ta strona jest dla programistów, którzy oddają pisanie testów Codexowi, i dla tech leadów, którzy decydują, co pull request z wygenerowanymi testami musi udowodnić przed merge’em. Polecenia sprawdzono na Codex CLI 0.157.1 w dniu 2026-09-26.

Co zyskasz na generowaniu testów z Codexem

• Układ torów, w którym kilka zadań testowych Codexa działa równolegle w osobnych worktree, nie dotykając siebie nawzajem ani twojego katalogu roboczego.
• Trzy prompty do skopiowania: analiza luk, testy zgodne z konwencjami projektu i krytyczny audyt wygenerowanych testów.
• Skrypt bramki, który odrzuca każdy tor zmieniający kod źródłowy, oraz kontrolę przyrostu pokrycia na plik.
• Testy mutacyjne ze StrykerJS, które pokazują, czy nowe testy łapią błędy, a nie tylko wykonują linie.
• Cotygodniowy raport o kondycji testów do uruchamiania z harmonogramu i tabelę awarii ze sposobem wyjścia z każdej.

Jeśli worktree w Codexie są dla ciebie nowe, zacznij od strony izolowane zadania Codexa w worktree Git. Debugowanie padającego testu to inne zadanie, opisane w debugowaniu i polowaniu na błędy z Codexem.

Kto co sprawdza, gdy testy pisze Codex?

Procent pokrycia to liczba, o którą wszyscy pytają, i najsłabszy dowód, jaki masz. Test, który wywołuje funkcję i niczego nie sprawdza, podnosi pokrycie linii tak samo jak dobry test. Podziel pracę tak, żeby każdy artefakt miał kontrolę, która nie jest opinią samego Codexa.

Artefakt	Kto go tworzy	Jak jest weryfikowany	Kto zatwierdza
Lista plików do przetestowania według priorytetu	Codex, tylko do odczytu	Czytasz 10 linii, nie kod	Programista
Planowane nazwy testów w torze	Codex	Czytasz listę, zanim powstanie jakikolwiek test	Programista
Wygenerowane pliki testów	Codex, w torze w worktree	Bramka „tylko testy”; pięć zielonych przebiegów z rzędu	Skrypt bramki
Przyrost pokrycia	Uruchomienie testów	Różnica na plik względem bazowego pomiaru toru	Skrypt bramki
Skuteczność w łapaniu błędów	StrykerJS	Wynik mutacyjny i lista mutantów, które przeżyły	Recenzent czyta ocalałe mutanty
Jakość testów	Drugi przebieg Codexa	codex review i prompt audytowy	Recenzent czyta ustalenia
Merge	CI	Pełny zestaw testów, typy i lint na czystej maszynie	Właściciel kodu, na podstawie dowodów

Dlaczego zielony zestaw testów sam w sobie niczego nie dowodzi i jak silny musi być, zanim przestaniesz go czytać, wyjaśnia strona jak silna jest twoja wyrocznia?

Przygotuj repozytorium, zanim Codex napisze pierwszy test

1. Wpisz polecenia testowe do AGENTS.md. Codex czyta AGENTS.md przed rozpoczęciem pracy, więc uruchamia twoje polecenia zamiast zgadywać. Od Codex CLI 0.150.0 niezaufany projekt nie dostarcza swojego projektowego AGENTS.md, dlatego najpierw oznacz repozytorium jako zaufane: uruchom codex w katalogu głównym repozytorium i zaakceptuj pytanie Trust this folder?.

   ## Tests
   - One file: `npx vitest run tests/unit/services/orders/createOrder.test.ts`
   - Full suite: `npx vitest run`
   - Coverage: `npx vitest run --coverage --coverage.reporter=json-summary --coverage.reporter=text`
   - Tests live in tests/unit/ and tests/integration/, mirroring src/.
   - Never edit a test to make it pass, and never change src/ in a test-writing task.

   Więcej o tym pliku w artykule jak pisać AGENTS.md dla Codexa.

2. Zapisz raport pokrycia dla commita bazowego. Uruchom samodzielnie polecenie pokrycia z listy powyżej. Reporter json-summary zapisuje coverage/coverage-summary.json, z którego korzysta prompt analizy luk i z którym później porównuje się bramka. Flaga pokrycia wymaga zainstalowanego pakietu @vitest/coverage-v8; jeśli repozytorium go nie ma, najpierw wykonaj krok 4.

3. Opcjonalnie zainstaluj skill „najpierw test”. Skill tdd z mattpocock/skills sprawia, że Codex planuje zachowania, zanim napisze testy. Zainstaluj go na poziomie projektu poleceniem npx skills add mattpocock/skills --skill tdd codebase-design -a codex -y. Skill codebase-design jest w poleceniu, bo tdd sięga po niego po słownictwo, a sam tdd zostawiłby to odwołanie bez celu. Opcje i pułapki opisuje strona skille do testowania i debugowania.

4. Przygotuj testy mutacyjne na gałęzi bazowej. Późniejsza kontrola mutacyjna potrzebuje StrykerJS w każdym torze, a flaga pokrycia wymaga zainstalowanego pakietu @vitest/coverage-v8, więc oba trafiają do tego samego commita bazowego. Zainstaluj go, skonfiguruj i wyklucz jego wyniki z repozytorium w jednym commicie, a ten commit wprowadź do gałęzi domyślnej (przez pull request, jeśli gałąź jest chroniona), zanim utworzysz pierwszy tor:

   npm install -D @vitest/coverage-v8 @stryker-mutator/core @stryker-mutator/vitest-runner
   echo '{ "testRunner": "vitest" }' > stryker.config.json
   printf 'reports/\n.stryker-tmp/\n' >> .gitignore
   git add package.json package-lock.json stryker.config.json .gitignore
   git commit -m "Add StrykerJS and the Vitest coverage provider"

   Stryker zapisuje raport HTML w reports/mutation/, a kopie robocze w .stryker-tmp/, więc oba katalogi muszą być ignorowane, inaczej bramka „tylko testy” zgłosi je jako zbędne pliki. Tory odgałęziają się od origin/main, więc każdy dziedziczy tę konfigurację, a żaden tor nie dotyka package.json.

Znajdź luki w pokryciu, które warto zamknąć najpierw

Niskie pokrycie w module ładującym konfigurację znaczy mniej niż niskie pokrycie gałęzi w kodzie, który obsługuje pieniądze. Poproś Codexa o ranking luk i zostaw go w trybie tylko do odczytu: analiza nie potrzebuje prawa zapisu.

Prompt do skopiowania: ranking luk w pokryciu według ryzyka

Read coverage/coverage-summary.json and the source files it lists.
Do not modify any file and do not run the test suite.

Rank the 10 files where missing tests carry the most risk. Weigh branch
coverage over line coverage, and weigh code that moves money, changes
persisted state, or enforces permissions over utilities and config.

For each file give: path, line %, branch %, the uncovered functions or
branches by name, and one sentence on what breaks in production if that
path is wrong. Then group the 10 files into at most 4 lanes of related
files that one agent can test without touching another lane's files.
Output a Markdown table followed by the lane list.

Uruchom go interaktywnie albo bez nadzoru, z sandboxem tylko do odczytu i bez zapisywania sesji:

codex exec --sandbox read-only --ephemeral -o coverage-gaps.md - < rank-gaps.txt

Plik rank-gaps.txt zawiera powyższy prompt. Czytasz coverage-gaps.md, poprawiasz podział na tory i na tym etapie zatwierdzasz tylko tę dziesięciowierszową tabelę.

Generuj testy w równoległych torach w worktree

Każdy tor dostaje własny worktree i własną gałąź, więc dwóch agentów nigdy nie edytuje tego samego katalogu, a nieudany tor usuwasz bez sprzątania w swoim. git worktree add daje nazwane gałęzie, z których później powstają pull requesty; codex --worktree to interaktywna alternatywa, gdy prowadzisz jeden tor ręcznie. Ile torów uruchamiać naraz i w jakiej kolejności je scalać, opisuje strona przepływy wieloagentowe w Codexie.

1. Utwórz po jednym worktree na tor i sam zainstaluj zależności. Nowy worktree nie ma node_modules ani plików ignorowanych przez Git. Instaluj z własnego terminala, bo sandbox przestrzeni roboczej odcina Codexowi dostęp do sieci. Potem zapisz bazowy pomiar pokrycia dla samego toru: kluczami w podsumowaniu są ścieżki bezwzględne, więc pomiar z głównego katalogu roboczego nie pasuje do plików toru.

   git fetch origin
   for lane in orders payments auth; do
     git worktree add -b "tests/$lane" "../app-tests-$lane" origin/main
     (cd "../app-tests-$lane" && npm ci \
       && npx vitest run --coverage --coverage.reporter=json-summary >/dev/null \
       && cp coverage/coverage-summary.json "/tmp/coverage-before-$lane.json")
   done

   Zastąp origin/main swoją domyślną gałęzią, a nazwy torów tymi z analizy luk.

2. Zatwierdź planowane nazwy testów w każdym torze. Uruchom codex w worktree toru, wklej poniższy prompt generujący i zatrzymaj się na liście nazw testów. Przeczytanie 15 nazw zajmuje minutę; przeczytanie 400 linii kodu testów po prostu się nie wydarzy. Dopisz każde brakujące zachowanie, na którym ci zależy.

3. Uruchom tory. Kontynuuj każdą zatwierdzoną sesję interaktywnie albo zapisz prompt każdego toru z dopisanymi zatwierdzonymi nazwami i uruchom tory równolegle, bez nadzoru:

   for lane in orders payments auth; do
     codex exec -C "../app-tests-$lane" -c default_permissions=":workspace" \
       --ephemeral -o "/tmp/lane-$lane.md" - < "prompts/tests-$lane.txt" &
   done
   wait

   default_permissions=":workspace" wybiera wbudowany profil uprawnień przestrzeni roboczej, który w 0.157.1 jest w wersji beta; w wersji Codexa bez profili użyj zamiast tego --sandbox workspace-write. Nie łącz obu: OpenAI pisze, że profili uprawnień i starszego systemu sandboxa nie da się łączyć. Wszystkie flagi i opcje wyjścia codex exec opisuje strona Codex w trybie nieinteraktywnym.

Prompt do skopiowania: testy zgodne z konwencjami dla jednego toru

You are in a Git worktree for one test-writing lane. Work only here.
Target files:
- src/services/orders/createOrder.ts
- src/services/orders/cancelOrder.ts
- src/services/orders/refundOrder.ts

1. Read tests/unit/services/payments/capturePayment.test.ts and
   tests/unit/services/users/createUser.test.ts. List the conventions:
   describe/it nesting, mock setup, fixture helpers in tests/fixtures/,
   assertion style and test naming.
2. List the test names you plan to write, one line each. Cover every
   exported function, every thrown error, every catch branch, and the
   boundaries: zero, empty list, maximum length, expired or already
   cancelled state. Stop here if I am in the session; otherwise continue.
3. Write the tests in tests/unit/services/orders/<functionName>.test.ts
   using exactly those conventions. Mock only true external edges (the
   database client, the payment provider, the email sender). Assert
   observable results: return values, thrown errors, persisted rows and
   calls that ARE the behaviour (an email sent, a refund issued), never
   internal helper calls.
4. Do not modify anything under src/. If a test exposes what looks like
   a bug, keep the test, mark it `it.skip` with a comment starting
   `BUG?:` that says what you expected, and list it in your report.
5. Run each new file with `npx vitest run <file>` until it passes, then
   run the full suite. Do not commit.

Report: files created, test count per file, the full-suite result with
its exit code, and every BUG?: test.

Reguła BUG?: jest kluczowa. Gdy test pada, bo kod jest błędny, najprostsza droga do zielonego wyniku to dopasować asercję do błędu. Zakaz zmian w kodzie źródłowym i prośba o oznaczony, pominięty test zamieniają ukryty błąd w linię raportu, którą sam oceniasz.

Udowodnij, że wygenerowane testy łapią błędy, bez czytania ich

Uruchom te kontrole w każdym torze, zanim otworzysz choć jeden plik testów, i zatrzymaj się na pierwszej porażce. Dwie pierwsze są mechaniczne, dwie ostatnie mierzą siłę testów.

1. Bramka „tylko testy”. Tor piszący testy, który zmienił kod źródłowy, jest odrzucany niezależnie od wyników:

#!/usr/bin/env bash
# tests-only-gate.sh LANE — run from inside the lane's worktree
set -euo pipefail
lane="$1"
stray=$(git status --porcelain --untracked-files=all | cut -c4- | grep -v -E '^tests/' || true)
[ -z "$stray" ] || { echo "FAIL: lane changed files outside tests/:"; echo "$stray"; exit 1; }

# The new tests must pass five times in a row: a flaky generated test is worse than none
for i in 1 2 3 4 5; do npx vitest run tests/ >/dev/null || { echo "FAIL on run $i"; exit 1; }; done

# Per-file branch-coverage change against this lane's own baseline
npx vitest run --coverage --coverage.reporter=json-summary >/dev/null
node -e '
const a = require(process.argv[1]), b = require("./coverage/coverage-summary.json");
for (const f of Object.keys(b)) {
  if (f === "total") continue;
  const d = b[f].branches.pct - (a[f]?.branches.pct ?? 0);
  if (d !== 0) console.log(d.toFixed(1).padStart(6), f);
}' "/tmp/coverage-before-$lane.json"
grep -rn "BUG?:" tests/ || true

Bramka zakłada, że katalog coverage/ jest ignorowany przez Git. Jeśli pliku docelowego nie ma w wyniku pokrycia, testy do niego nie dotarły, niezależnie od ich liczby. Odeślij tor z powrotem, podając niepokrytą gałąź z numerem linii.

2. Testy mutacyjne. Pokrycie linii pokazuje, które linie się wykonały; testy mutacyjne pokazują, czy błędna linia zostałaby zauważona. StrykerJS wprowadza do kodu drobne zmiany (odwrócony warunek, usunięta gałąź, > zamiast >=) i ponownie uruchamia testy; mutant, który przeżył, wskazuje zachowanie, którego żaden test nie pilnuje. W próbnym przebiegu z jednym testem tylko dla scenariusza pozytywnego Stryker 10.0.0 zgłosił pełne pokrycie linii, a mimo to znalazł mutanty, które przeżyły. Właśnie tę lukę zamyka ta kontrola.

npx stryker run --mutate "src/services/orders/**/*.ts"

Stryker jest już w torze zainstalowany i skonfigurowany, bo tor odgałęził się od commita bazowego przygotowanego w kroku 4 konfiguracji. Ogranicz --mutate do plików docelowych toru: przebieg na całym repozytorium trwa znacznie dłużej i nic nie mówi o tym torze. Poziom, do którego warto dążyć, i sposób czytania ocalałych mutantów opisuje strona jak silna jest twoja wyrocznia?

3. Przebieg recenzji. Uruchom w torze codex review --uncommitted, żeby dostać wbudowaną recenzję Codexa, albo wpisz /review w sesji interaktywnej i pokieruj nią promptem audytowym poniżej. W 0.157.1 codex review nie przyjmuje własnych instrukcji razem z --uncommitted ani --base (sprawdzone 2026-09-26), więc stałe reguły w rodzaju „oznacz testy bez sensownej asercji” trafiają do AGENTS.md. Tę samą konfigurację recenzenta w skali pull requestów opisuje strona code review z Codexem.

Prompt do skopiowania: krytyczny audyt wygenerowanych testów

Audit the uncommitted test files in tests/ as if you want to prove them
useless. Do not edit any file.

For each test, answer:
1. Would this test still pass if the function under test returned a
   hard-coded value, threw nothing, or skipped its database write?
2. Does it assert only that a mock was called, or that a value is
   truthy or defined?
3. Does a mock return a shape the real dependency never returns? Check
   the real implementation of each mocked module before answering.
4. Does it depend on test order, wall-clock time or shared state?

Then take the surviving mutants from the Stryker output I paste below
and, for each one, name the missing assertion and the test it belongs in.
Output a table: test name, problem (or "ok"), fix in one sentence.

4. Dowody do pull requesta. Gdy bramka przejdzie, sam zacommituj tor, wypchnij gałąź i otwórz pull request z przyrostem pokrycia, wynikiem mutacyjnym i listą ocalałych mutantów, listą BUG?: i tabelą z audytu. Recenzenci czytają te dowody i otwierają tylko testy, które one wskazują. Co pull request powinien dołączyć, definiuje pakiet dowodów. Żeby późniejsze zadanie nie osłabiło tych testów, dodaj tests/ do CODEOWNERS i kontrolę CI opisaną w artykule ochrona wyroczni.

Nie pozwól, żeby pokrycie i kondycja testów znów spadły

Zestaw testów silny we wrześniu słabnie, gdy nowy kod trafia do repozytorium bez testów. Dwie kontrole trzymają poziom.

Po pierwsze, niech CI pilnuje progu. Ustawienie coverage.thresholds w konfiguracji Vitest sprawia, że przebieg kończy się błędem, gdy pokrycie spadnie poniżej ustalonych wartości; podnoś je po każdym scalonym torze i nigdy nie obniżaj, żeby przepchnąć pull request. Jak podpiąć to zadanie do GitHub Actions, opisuje strona CI/CD z Codexem.

Po drugie, zaplanuj cotygodniowy raport o kondycji testów. Automatyzacje Codexa w aplikacji desktopowej uruchamiają prompt według harmonogramu; zadanie cron w CI z codex exec robi to samo z poziomu pipeline’u. Kompromisy, wybór sandboxa i typowe awarie opisuje strona zaplanowane automatyzacje Codexa.

Raz zacommituj podsumowanie z kroku 2 jako coverage-baseline.json, żeby pierwszy zaplanowany przebieg miał z czym porównywać.

Prompt do skopiowania: cotygodniowy raport o kondycji testów

Weekly test-health check. Do not modify source or test files.
1. Run `npx vitest run` three times. List every test that failed in some
   runs but not all: those are flaky. For each, name the likely cause
   (timer, shared state, ordering, network) with the line that shows it.
2. Run the coverage command from AGENTS.md and compare
   coverage/coverage-summary.json with coverage-baseline.json. The summary
   keys are absolute paths, so match files by their path relative to the
   repository root, not by the full key. List every
   file whose branch coverage dropped by more than 2 points, and the
   commits since last week that touched it (`git log --since=7.days -- <file>`).
3. List every test marked `it.skip` or `it.todo`, oldest first.
Report: test count, flaky tests, coverage drops, skipped tests. Do not
propose fixes unless a test failed in all three runs.

Plik coverage-baseline.json aktualizuj ręcznie, w recenzowanym commicie, po scaleniu toru. Zadanie, które samo nadpisuje swój punkt odniesienia, może ukryć regresję w tym samym przebiegu, w którym ją wywołało.

Co się psuje przy generowaniu testów z Codexem

Objaw	Przyczyna	Jak wyjść
Pokrycie wzrosło, wynik mutacyjny został niski	Testy wykonują kod, ale sprawdzają tylko wywołanie mocka albo to, że wartość jest niepusta lub zdefiniowana	Uruchom prompt audytowy; odeślij tor z ocalałymi mutantami jako wymaganymi asercjami
Bramka zgłasza pliki spoza tests/	Codex „naprawił” kod, żeby test przeszedł	Odrzuć te zmiany przez git checkout -- src/; uruchom tor ponownie z regułą BUG?:; sam oceń oznaczone zachowanie
Plik docelowy nie pokazuje zmiany pokrycia	Testy importują mocka albo moduł spod innej ścieżki	Wskaż niepokrytą gałąź z numerem linii i poproś Codexa o pomiar pokrycia tylko dla tego pliku
Testy przechodzą w torze, padają po scaleniu	Tor wyszedł ze starszej bazy albo dwa tory zmieniły wspólną fiksturę	Zrób rebase toru na aktualną bazę i ponownie uruchom bramkę; trzymaj fikstury w jednym torze albo w osobnej, wcześniejszej zmianie
Mocki rozjeżdżają się z rzeczywistością	Mocki napisano z perspektywy testu, nie zależności	Poproś o mocki zbudowane z typów prawdziwego modułu; dodaj jeden test integracyjny na każdy styk, jak we wzorcach testów integracyjnych
Tory padają na pierwszym poleceniu z brakującymi modułami	Worktree nie ma node_modules, a sandbox blokuje instalację	Uruchom npm ci w torze z własnego terminala, potem wznów tor
Testy zaczęły działać wolno	Każdy wygenerowany test integracyjny stawia własną bazę danych	Wymagaj wspólnego przygotowania w beforeAll i transakcji na test; zobacz zarządzanie danymi testowymi
Codex ignoruje twoje polecenia testowe	Projekt jest niezaufany, więc AGENTS.md nie został wczytany (0.150.0 i nowsze)	Uruchom codex w katalogu głównym repozytorium i zaakceptuj Trust this folder?, potem zapytaj Codexa, jakie instrukcje wczytał; szczegóły w artykule jak pisać AGENTS.md dla Codexa

Dokąd dalej po wygenerowaniu testów z Codexem

Ochrona wyroczni Zablokuj ścieżki testów, żeby późniejsze zadanie agenta ich nie osłabiło

Code review z Codexem Ten sam recenzent przy każdym pull requeście

Strategie testów jednostkowych Co testować i jak mockować, w każdym agencie

Testowanie i debugowanie z Codexem Przegląd tego etapu i kolejność konfiguracji

Używasz też innego agenta? To samo zadanie opisują strony generowanie testów i TDD z Claude Code oraz wzorce testowania w Cursorze.