Use before implementing or refactoring software. Contains two skills: (1) Modular Software Design — for designing module boundaries, APIs, layers, abstractions, services, repositories, adapters, or architecture, helping reduce total system complexity by creating deep modules, hiding implementation knowledge, avoiding leakage and pass-through APIs, comparing alternative designs, documenting interfaces before coding, and critiquing existing architecture; and (2) Software Testing — for writing unit tests, integration tests, or end-to-end tests, creating mocks/stubs/fakes, designing a testing strategy, doing TDD, reviewing test quality, fixing flaky tests, or refactoring test suites, generating risk-focused test plans, picking appropriate test levels, choosing between mocks/fakes/real dependencies, and applying Arrange-Act-Assert patterns with concrete examples.
88
88%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Symptom: Refactoring breaks many tests even though behaviour is unchanged; arrange sections dominated by expectation setup; tests "know" the call graph.
Fix: Assert end result; collapse internal collaborators into the unit boundary; replace mocks with fakes or spies; move mocks to external side effects only.
Symptom: Coverage numbers look strong, but tests only check existence, status codes, or one shallow field.
Fix: Strengthen the oracle around business-critical outputs, state transitions, invariants, and negative cases; use mutation-oriented thinking to ask what change would survive.
Symptom: Reruns pass; failures cluster around time, concurrency, order dependence, remote services, or shared state.
Fix: Improve isolation; remove shared mutable fixture state; control time and async boundaries; quarantine only temporarily; keep unit suite free of flakiness.
Symptom: Reader cannot tell from the test alone why the fixture leads to the assertion; large SQL files, global fixtures, or hidden setup determine outcomes.
Fix: Prefer explicit builders, minimal fixtures, and test-local setup that communicates only the facts needed to understand the scenario.
Symptom: Each test repeats noisy construction code, or shared helpers become so clever that the scenario disappears.
Fix: Use builders and small helper abstractions, but keep the test readable from top to bottom.
Symptom: Tests need magic hooks, global state management, or huge object graphs.
Fix: Make dependencies explicit; split business logic from orchestration; introduce ports/adapters; treat the difficulty of testing as design feedback rather than as a signal to buy more mocking tools.