Test Writer
When to use
- You implemented a feature and need a test suite before merging.
- Coverage dropped and you must close the gap.
- A bug escaped to production and you want a regression test.
Workflow
- Identify the contract. What are the inputs, the outputs, and the side effects? Tests assert the contract, not the implementation.
- Start from the happy path. One clear test that proves the normal case works.
- Add boundary and edge cases: empty input,
None, max/min values, off-by-one, duplicates, very large input, unicode/encoding, timeouts. - Add failure paths. What exceptions are raised, and with what messages? Assert the
exact exception type, not a bare
Exception. - Add a regression test if this is for a reported bug — name it after the bug.
- Keep tests independent. No shared mutable state between tests; each sets up its own fixtures and tears them down.
Constraints
- Tests must be deterministic. Avoid real network, real clocks, and randomness unless explicitly mocked.
- Don't test framework internals. Test behavior the caller relies on.
- One behavior per test; a misleading name is worse than no test.
Definition of done
- Happy path + edge cases + failure paths each have at least one test.
pytest(or the project's runner) is green locally.- A previously failing case is now covered by a regression test.