testing
Installation
SKILL.md
Testing — Strategy & Philosophy
Testing is not verification after the fact. It is feedback on design. A test that is hard to write reveals coupling in production code. A test that is hard to name reveals unclear thinking about behavior. The test suite is the living specification of the system — what the code is actually supposed to do. That's true whether a human or an AI agent wrote the code.
Core Beliefs
| Belief | What it means in practice | Anti-pattern it prevents |
|---|---|---|
| Hard to test = design problem | Refactor the design, not the test | Mocking everything to force testability |
| Tests are specification, not verification | Name tests as sentences describing behavior | Tests named after implementation details |
| Mocks are a smell, not a strategy | Prefer real collaborators or fakes | Mock-heavy suites that survive bugs |
| Pure functions are the testability ideal | Push I/O to the edges; keep business logic pure | Business logic tangled with side effects |
| Green must mean releasable | A failing build is a stop-the-line signal, not noise | Retrying flaky tests until the suite happens to pass |
| Test behavior, not design principles | SRP and other architectural rules guide how code is structured; assert what the code does, not whether it obeys a design rule | Tests that count methods, check class responsibilities, or assert SOLID compliance instead of observable outcomes |