Generowanie i uruchamianie testów z Codex

Twój raport pokrycia kodu pokazuje 34%, a tech lead właśnie zarządził 80% przed następnym wydaniem. Masz 200 niepokrytych funkcji w 40 plikach. Pisanie tych testów ręcznie zajęłoby dwa tygodnie. Z Codex możesz uruchomić wątki worktree generujące testy dla różnych modułów równolegle, uruchamiać je w izolacji i synchronizować przechodzące zestawy z powrotem do twojej gałęzi w jedno popołudnie.

Co wyniesiesz z tej lekcji

Workflow równoległego generowania testów za pomocą worktree do pokrycia wielu modułów jednocześnie
Prompty generujące testy dopasowane do twoich istniejących konwencji testowych, nie ogólnikowy boilerplate
Technika użycia CLI /review do audytowania jakości testów przed mergowaniem
Przepis na automatyzację nocnego monitorowania pokrycia testów

Workflow

Krok 1: Przeanalizuj luki w pokryciu

Zacznij w CLI, aby szybko uzyskać 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 równoległych worktree

Weź priorytetową listę i podziel ją na równoległe strumienie pracy. W Codex App utwórz wątek worktree dla każdego modułu lub grupy powiązanych plików. Każdy worktree dostaje własną izolowaną kopię repozytorium, więc agenci mogą uruchamiać testy bez wzajemnego przeszkadzania.

Wątek Worktree 1: Testy warstwy serwisów

Gotowy prompt do generowania testów warstwy serwisów:

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.

Wątek 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.

Wątek Worktree 3: Testy przypadków brzegowych i ścieżek błędów

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 pomocą /review

Przed zmergowaniem jakichkolwiek wygenerowanych testów użyj komendy /review, aby Codex zaudytował jakość testów. W CLI otwórz sesję 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 otwórz panel recenzji dla każdego worktree i zostaw komentarze inline przy podejrzanych testach. Następnie wyślij kontynuację: “Address the inline comments and improve the flagged tests.”

Krok 4: Zsynchronizuj i zweryfikuj pokrycie

W miarę jak każdy wątek worktree kończy pracę, zsynchronizuj wyniki z powrotem do lokalnego checkoutu za pomocą Sync with local z metodą Apply. Po zsynchronizowaniu każdej partii:

npm run test:coverage

Sprawdź, czy pokrycie faktycznie wzrosło. Codex czasem generuje testy, które wyglądają na kompleksowe, ale nie pokrywają odpowiednich ścieżek kodu. Jeśli pokrycie dla konkretnego pliku nie wzrosło, wróć do tego wątku worktree i bądź 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 automatyzację w Codex App do monitorowania pokrycia i powiadamiania cię, 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 każdego uruchomienia, sprawdza pokrycie i dodaje wyniki do twojej skrzynki w panelu automatyzacji.

Gotowy prompt automatyzacji do cotygodniowej kontroli zdrowia testów:

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 coś się nie uda

Wygenerowane testy przechodzą, ale nie testują właściwej rzeczy. Najczęstszy tryb awarii to testy asertujące szczegóły implementacji (funkcja została wywołana z dokładnie tymi argumentami) zamiast zachowania (dla tego wejścia, wyjście 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 przechodzą, ale nie po zsynchronizowaniu do lokalnego. Dzieje się tak, gdy worktree został utworzony z gałęzi, która od tamtej pory się rozjechała. Rozwiązanie: twórz worktree z najnowszego commita na gałęzi funkcji, nie ze stałego punktu wyjścia. Lub użyj Sync from local przed uruchomieniem testów w worktree, aby wciągnąć ostatnie zmiany.

Mocki nie odpowiadają rzeczywistej implementacji. Jeśli kod testowany zmienił się po napisaniu mocków, testy przechodzą względem nieaktualnego zachowania. Dołącz “read the current implementation of each dependency before writing mocks” w swoim prompcie.

Zestaw testów staje się wolny. Przy generowaniu wielu testów równolegle możesz skończyć z testami integracyjnymi, z których każdy uruchamia bazę danych. Dodaj “use shared test database setup and teardown, not per-test database creation” do swoich ograniczeń.

Co dalej

Refaktoryzacja na dużą skalę z Worktree Zastosuj wzorzec równoległych worktree do refaktoryzacji setek plików

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