Writing Tests
Gates whether a new test should exist and forces it to be efficient, protecting CI from...
Install
npx skills add amplifthq/openmeld --skill writing-tests -g -a claude-code -y- Repository
- amplifthq/openmeld1.4k
- Category
- Testing
- Updated
- 3d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Gates whether a new test should exist and forces it to be efficient, protecting CI from low-value test bloat. Use before any change to what a pytest, Jest, or Playwright test asserts or sets up, down to one fixture or one assertion added to an existing block. Front-loads the value bar (every test must catch a realistic regression no existing test already catches; extend the nearest existing test before writing a new standalone one; test behavior through the public interface, not implementation details; collapse near-duplicates into parameterized cases) and the efficiency bar (deterministic, isolated, fast; pick the cheapest test level; Django TestCase over TransactionTestCase; no sleeps, no real network; no time bombs from absolute dates left to age against the real clock; no database a test never uses). Includes a "don't write it" decision tree. For fixing an existing flaky test use `/fixing-flaky-tests`; after this gate says a Playwright test is warranted, use `/playwright-test` for mechanics.
Writing tests worth keeping
The rationale and the same rules in human-facing form live in the handbook: Backend coding conventions › Testing (docs/published/handbook/engineering/conventions/backend-coding.md).
This skill is the operational gate, run it before writing tests. It carries the decision procedure plus a catalog of the bug shapes we actually ship.
The gate covers added coverage, not new test functions. One fixture and one assertion added to an existing block goes through the same two questions, because that is the shape this skill asks you to prefer.
The gate: two questions
Before writing any test, answer both in one sentence each.
1. Does it earn its place?
What realistic regression does this test catch that no existing test already catches?
If you can't answer it concretely, name the bug, the code path, the input that would break, do not write the test. "Increases coverage", "good practice", and "the function exists" are not answers.
A good answer sounds like: "if someone makes parse_filters drop the team_id clause, this fails" or "empty-cohort input used to 500; this locks in the 400."
That is a test worth keeping.
Aim each test at a failure mode we actually hit, not a hypothetical. The bugs PostHog ships and reverts cluster into a handful of shapes, cataloged with the test that catches each, and the failure modes no unit test should, in references/mistakes-we-make.md. If your test doesn't map to one of them, be skeptical it's worth keeping.
2. Where does it go?
Passing the first question buys the coverage, not a new test function. Find the test that already covers the nearest behavior and answer:
Why can't this be a case in that test?
