test-driven-developmentlisted

# Test-Driven Development **For system-level design principles and architectural boundaries, see the `software-engineer` skill.** ## Core Philosophy <core_philosophy> **Foundation**: TDD is an application of contract-based design. Tests define the contract an implementation must fulfill—they are specifications, not afterthoughts. This connects directly to the abstraction principles in the `software-engineer` skill. **Tests = Contracts**: Tests represent business requirements and expected behavior. They are contracts the implementation must fulfill. Never compromise test integrity to achieve green tests. **Tests are source of truth**: When tests fail, fix the implementation. Only change tests when requirements change or test has a verified bug. </core_philosophy> ## Testing Approach ### Architectural Boundaries and Mocking Strategy <architectural_boundaries> **Identify architectural boundaries** in your system: - Layer boundaries (e.g., data layer, service layer, presentation layer) - Module boundaries (e.g., namespaces, packages, crates) - Process boundaries (e.g., Erlang processes, Elixir GenServers) - External system boundaries (e.g., APIs, databases, third-party services) </architectural_boundaries> <unit_definition> **What constitutes a "unit":** A "unit" is a cohesive component at an architectural boundary: - Classes (e.g., Java, Python, Swift) - Namespaces with related functions (e.g., Clojure, Haskell) - Modules with related predicates (e.g., Prolog) - Proces