A skill for writing and reviewing unit and end-to-end tests. It rejects coverage-padding filler and insists every test verifies real behavior — with one sharp rule about not wiping parallel test data.
---
name: writing-tests
description: Use when writing or reviewing unit/api-flow (e2e) tests in this codebase. Triggers when adding tests, doing TDD, or fixing a bug that needs a regression test.
---
Use when writing or reviewing unit/api-flow (e2e) tests in this codebase. Triggers when adding tests, doing TDD, or fixing a bug that needs a regression test.
Guidance:
- Add real, meaningful tests that verify behavior; no filler/coverage-padding tests.
- Use TDD where applicable (write the failing test first).
- Cover positive AND negative cases and all branches explicitly.
- Prefer real mocks (real SSE/LLM responses, MSW) over hand-written manual mocks.
- Every bug fix gets a regression test that fails before the fix.
- Scope test-data deletion to the test file — never deleteMany with an empty filter (it wipes parallel test data).
- Report pass counts per suite when done.A regression test per bug#
Every fix ships with a test that fails before it and passes after — the proof the bug is actually gone and a guard against its return.
Don't wipe parallel data#
The most operationally important rule: scope test-data deletion to the current test file. A delete-many with an empty filter wipes the data other suites are using in parallel, turning one bad teardown into a flood of unrelated failures.
What to delete#
Delete tests that only assert imports exist, mocks echo inputs, or typed config has a key. Those are compiler checks wearing a test name.
Replace them with behavior coverage where the product can actually regress: permissions, retries, parsing, money math, data writes, API errors, and UI states users depend on.