Generowanie i uruchamianie testow z Codex

Twoj raport pokrycia kodu pokazuje 34%, a tech lead wlasnie zarzadzil 80% przed nastepnym wydaniem. Masz 200 niepokrytych funkcji w 40 plikach. Pisanie tych testow recznie zajaloby dwa tygodnie. Z Codex mozesz uruchomic watki worktree generujace testy dla roznych modulow rownolegle, uruchamiac je w izolacji i synchronizowac przechodzace zestawy z powrotem do twojej galezi w jedno popoludnie.

Co wyniesiesz z tej lekcji

Workflow rownoleglego generowania testow za pomoca worktree do pokrycia wielu modulow jednoczesnie
Prompty generujace testy dopasowane do twoich istniejacych konwencji testowych, nie ogolnikowy boilerplate
Technika uzycia CLI /review do audytowania jakosci testow przed mergowaniem
Przepis na automatyzacje nocnego monitorowania pokrycia testow

Workflow

Krok 1: Przeanalizuj luki w pokryciu

Zacznij w CLI, aby szybko uzyskac obraz tego, co wymaga testowania:

Gotowy prompt do analizy pokrycia:

Run the test suite with coverage enabled (npm run test:coverage) and analyze the results. Identify the top 10 files with the lowest coverage that have the most business logic. For each file, report:

1. Current line and branch coverage percentage
2. Which functions are uncovered
3. How critical the uncovered code paths are (based on what the function does)

Prioritize files in src/services/ and src/routes/ over utilities and config files.

Krok 2: Generuj testy w rownoleglych worktree

Wez priorytetowa liste i podziel ja na rownolegle strumienie pracy. W Codex App utwroz watek worktree dla kazdego modulu lub grupy powiazanych plikow. Kazdy worktree dostaje wlasna izolowana kopie repozytorium, wiec agenci moga uruchamiac testy bez wzajemnego przeszkadzania.

Watek Worktree 1: Testy warstwy serwisow

Gotowy prompt do generowania testow warstwy serwisow:

Generate unit tests for the following service files:
- src/services/orders/createOrder.ts
- src/services/orders/cancelOrder.ts
- src/services/orders/refundOrder.ts

Requirements:
- Follow the testing patterns in tests/unit/services/ (look at existing tests first)
- Use the same test framework, assertion style, and mock patterns
- Cover the happy path, validation errors, database errors, and edge cases
- Mock external dependencies (database, payment provider, email service)
- Each test file should be independently runnable
- Name files consistently: tests/unit/services/orders/[functionName].test.ts

After writing the tests, run them and fix any failures. Then run the full test suite to ensure no regressions.

Watek Worktree 2: Testy tras API

Generate integration tests for the order API routes:
- POST /api/orders (create order)
- DELETE /api/orders/:id (cancel order)
- POST /api/orders/:id/refund (refund order)

Requirements:
- Follow patterns in tests/integration/ (read existing tests first)
- Use supertest for HTTP assertions
- Set up and tear down test database state in beforeEach/afterEach
- Test authentication (valid token, missing token, wrong user)
- Test validation (missing fields, invalid types, boundary values)
- Test error responses (404 for missing orders, 409 for already cancelled)

Run tests after writing them. Fix any failures.

Watek Worktree 3: Testy przypadkow brzegowych i sciezek bledow

Audit the existing tests in tests/ and identify missing edge case coverage for:
- Error handling paths that are never tested
- Boundary conditions (empty arrays, null values, maximum lengths)
- Concurrent access scenarios
- Timeout and retry behavior

Write tests for the top 15 missing edge cases you find. Follow existing test conventions. Run the full suite after adding them.

Krok 3: Przejrzyj wygenerowane testy za pomoca /review

Przed zmergowaniem jakichkolwiek wygenerowanych testow uzyj komendy /review, aby Codex zaudytowal jakosc testow. W CLI otworz sesje i uruchom:

/review Focus on test quality: Are the assertions meaningful or just checking truthy values? Are the mocks realistic? Do the tests actually exercise the code paths they claim to cover? Flag any tests that would pass even if the implementation was wrong.

Lub w App otworz panel recenzji dla kazdego worktree i zostaw komentarze inline przy podejrzanych testach. Nastepnie wyslij kontynuacje: “Address the inline comments and improve the flagged tests.”

Krok 4: Zsynchronizuj i zweryfikuj pokrycie

W miare jak kazdy watek worktree konczy prace, zsynchronizuj wyniki z powrotem do lokalnego checkoutu za pomoca Sync with local z metoda Apply. Po zsynchronizowaniu kazdej partii:

npm run test:coverage

Sprawdz, czy pokrycie faktycznie wzroslo. Codex czasem generuje testy, ktore wygladaja na kompleksowe, ale nie pokrywaja odpowiednich sciezek kodu. Jesli pokrycie dla konkretnego pliku nie wzroslo, wroc do tego watku worktree i badz bardziej konkretny:

The tests you generated for createOrder.ts did not cover the discount calculation branch (lines 45-62). Write additional tests that exercise:
1. Orders with no discount
2. Orders with a percentage discount
3. Orders with a fixed amount discount that exceeds the order total
4. Orders with an expired discount code

Run coverage for just this file and confirm those lines are now covered.

Krok 5: Zautomatyzuj monitorowanie pokrycia

Skonfiguruj automatyzacje w Codex App do monitorowania pokrycia i powiadamiania cie, gdy spadnie:

Run npm run test:coverage and compare the results to the last known coverage baseline in coverage-baseline.json. If any file's coverage dropped by more than 5 percentage points, report which files declined and suggest which new code paths need tests. If coverage improved or stayed stable, report that and update the baseline file.

Zaplanuj to na codzienne uruchamianie. Codex tworzy worktree dla kazdego uruchomienia, sprawdza pokrycie i dodaje wyniki do twojej skrzynki w panelu automatyzacji.

Gotowy prompt automatyzacji do cotygodniowej kontroli zdrowia testow:

Weekly test suite health check:

1. Run the full test suite. Report any failures.
2. Run coverage and compare to coverage-baseline.json.
3. Identify any flaky tests (tests that pass sometimes and fail sometimes) by running the suite 3 times.
4. Report: test count, pass rate, coverage delta, and any flaky tests.

If there are failures or flaky tests, investigate the root cause and propose minimal fixes.

Gdy cos sie nie uda

Wygenerowane testy przechodza, ale nie testuja wlasciwej rzeczy. Najczestszy tryb awarii to testy asertujace szczegoly implementacji (funkcja zostala wywolana z dokladnie tymi argumentami) zamiast zachowania (dla tego wejscia, wyjscie odpowiada temu kontraktowi). Powiedz Codex jawnie: “Test observable behavior, not implementation details. Do not assert on internal function calls unless testing side effects like database writes.”

Testy worktree przechodza, ale nie po zsynchronizowaniu do lokalnego. Dzieje sie tak, gdy worktree zostal utworzony z galezi, ktora od tamtej pory sie rozjechala. Rozwiazanie: twroz worktree z najnowszego commita na galezi funkcji, nie ze stalego punktu wyjscia. Lub uzyj Sync from local przed uruchomieniem testow w worktree, aby wciagnac ostatnie zmiany.

Mocki nie odpowiadaja rzeczywistej implementacji. Jesli kod testowany zmienil sie po napisaniu mockow, testy przechodza wzgledem nieaktualnego zachowania. Dolacz “read the current implementation of each dependency before writing mocks” w swoim prompcie.

Zestaw testow staje sie wolny. Przy generowaniu wielu testow rownolegle mozesz skonczyc z testami integracyjnymi, z ktorych kazdy uruchamia baze danych. Dodaj “use shared test database setup and teardown, not per-test database creation” do swoich ograniczen.

Co dalej

Refaktoryzacja na duza skale z Worktree Zastosuj wzorzec rownoleglych worktree do refaktoryzacji setek plikow

CI/CD z GitHub Action Codex Uruchamiaj generowanie testow i kontrole pokrycia automatycznie w pipeline CI