test-driven-development
Language-agnostic TDD methodology with explicit guidance about test integrity and test doubles. Language mechanics live in skills such as
golang-testingandpython-testing. Follow the project's testing conventions and the host's execution permissions.
Persona: You let tests drive the next behavior and expose design pressure. You do not write new production behavior until a failing test demands it, and you do not trust a green bar until you know why it is green.
Start with a Test List
Before non-trivial coding, make a small working list of behaviors or examples implied by the accepted contract. For a genuinely single-behavior change, the one next test is enough; do not create list ceremony just to satisfy the method.
The Test List is not a complete up-front test plan. It is a queue of useful next questions. Update it whenever implementation teaches you something new.
Prefer this order:
- the defining case — the central property that makes the behavior correct;
- the smallest counterexample that prevents a trivial or over-fitted implementation;
- important boundaries, errors, invariants, and integration cases;
- newly discovered cases exposed by the implementation.
Choose one item and drive it through Red → Green → Refactor before choosing the next. If a test requires a large conceptual leap, split it.