testabilitylisted

# /testability — Testable Design Enforcement Every design, plan, and implementation MUST produce code that is easy to test in isolation. If it's hard to test, the design is wrong — not the test. **Why this matters:** Untestable code is unverifiable code. When a simple test cannot be written for a component, it's because the component has too many hidden dependencies, side effects, or tightly coupled concerns. Testability is a direct measure of design quality. **When to invoke:** During PLANNING (after `/gsd:discuss-phase`, before `/gsd:plan-phase`) and during REVIEW (as part of code review criteria). This skill applies to both new code and modifications to existing code. --- ## The Rules ### Rule 1: Dependency Injection Over Hard-Wiring Every external dependency MUST be injectable — never hard-coded: | Hard-wired (untestable) | Injected (testable) | |--------------------------|---------------------| | `import { db } from './database'` at module level | `function getUser(db, userId)` | | `new PaymentProvider()` inside business logic | `function processPayment(provider, order)` | | `Date.now()` called directly | `function isExpired(clock, token)` | | `fetch('https://api.example.com')` inline | `function getPrice(httpClient, productId)` | **The rule:** If a function calls something external (DB, API, clock, filesystem, random), that thing MUST be a parameter or constructor argument — not an import or global. **Exception:** Pure utility libraries (lodash, date-fns) that