Test 8 Untested Modules in One Night
Launch 8 parallel sessions overnight to write unit tests and open PRs by morning.
Create a test-writing playbook
Connect GitHub and Sentry. The test-writing process follows a playbook, a reusable, named set of steps that ensures every run writes tests the same way. Define your test framework, mocking rules, file placement, coverage target, and forbidden actions.
For payment or sensitive modules, add the payment-specific rules: integer cents, mock the payment SDK, never call real APIs.
Playbook: !write-tests
For each module:
1. Read the module source and any existing tests.
2. Identify all exported functions and branches to cover.
3. Create a test file at {module}/__tests__/{filename}.test.ts.
4. Follow AAA pattern (Arrange, Act, Assert).
5. Mock external dependencies; never call real APIs or databases.
6. Use test helpers from src/test/helpers.ts.
7. Cover success, error, and edge cases.
8. Run npm test -- --coverage --reporter=json.
9. Verify the module exceeds 80% line coverage.
10. Open a PR with the before/after coverage numbers.
Forbidden:
- Modify source to make it easier to test.
- Skip flaky or mocked edge cases.
- Use floating-point currency math.Add your team's best existing test file as a memory entry so Opulent learns the assertion style, naming convention, and helper patterns without you repeating them in every prompt.
Find the 8 worst-covered modules
Run the coverage report and ask Opulent to list the modules with the lowest line coverage, excluding generated code. This gives you the batch target and the before numbers.
Run: npm run test:coverage Lowest coverage modules (skip src/generated/): | Module | Coverage | Exported functions missing tests | |--------|----------|----------------------------------| | src/services/PaymentService | 31% | processCharge, issueRefund, handleWebhook | | src/services/UserService | 38% | createUser, updateProfile, deleteAccount | | src/api/routes/billing | 42% | list, create, update, cancel | | src/middleware/auth | 44% | requireAuth, refreshToken | | src/services/NotificationSvc | 47% | sendEmail, sendPush | | src/components/Checkout | 49% | submit, validate, format | | src/utils/validation | 51% | isEmail, isUUID, isStrongPassword | | src/services/SearchService | 53% | search, index, autocomplete |
Launch the batch overnight
Start one Opulent run per module, all in parallel. Each run reads its module, writes tests, runs coverage, and opens a PR. Because each run only adds tests to its own module, conflicts are rare.
The batch can run overnight. In the morning, you have up to 8 PRs, each with a coverage summary.
Batch: 8 parallel test-writing runs
Modules: PaymentService, UserService, billing routes, auth
middleware, NotificationSvc, Checkout component,
validation utils, SearchService.
Each run:
- Attaches !write-tests playbook.
- Writes tests to 80%+ line coverage.
- Runs full suite to confirm no regressions.
- Opens a PR with before/after numbers.Review and merge
Review each PR for test quality, not just coverage. A PR that hits 80% with meaningful assertions is better than one that hits 90% by testing getters. If two runs touch a shared helper, merge the first and ask the second to rebase.
Track overall coverage across the batch. One night may move the codebase from 44% to 68%. Schedule the next batch for the next tier to reach 80%.
Sharpen the test batch loop
When a test misses a real bug, add a regression case and update the playbook. When the coverage metric is gamed with trivial tests, add branch-coverage or property-based checks.
Add an eval that fails if a PR's tests do not fail when the source function is broken. This is the real proof of coverage.
The natural chain: when tests reveal a bug, use Debug a Bug Report End-to-End; when the untested code is payment logic, use Add Unit Tests to Your Payments Service; when the same pattern spans many repos, use Fleet-Wide Maintenance Across Thousands of Repositories.