clean-architecture-testinglisted

# Clean Architecture Testing ## Overview Defines **where** to test and **with which doubles** in a Clean Architecture solution. Language-agnostic. Does NOT redefine the TDD cycle — that is owned by `outside-in-tdd`. **Core principle:** every test enters through **one boundary** and asserts at the next boundary. Choice of double follows the layer, not convenience. **REQUIRED SUB-SKILL:** Use `outside-in-tdd` for the RED → SYNTHESIZE-GREEN → COMMIT cycle. This skill only routes you to the correct layer and doubles. ## The Iron Rule for Domain Tests **Default = Application-level acceptance test.** Do NOT write Domain tests by default. Extract a Domain test ONLY when a business rule: - Has complex invariants or a large edge-case matrix, AND - Is extracted into a reusable Policy / Domain Service / Specification. **NEVER test directly:** - Constructors (unless they enforce complex invariants) - Simple value objects (covered by usage in Application acceptance tests) - Getters / setters / DTOs / ViewModels / passive data structures A test asserting `new PolicyNumber("abc").value == "abc"` is noise. It tests the compiler, not behavior. ## Test Project Organization **Rule: exactly two test projects per bounded context**, regardless of language. | Test project | Targets | Contains | |---|---|---| | `<Context>.UnitTest` | Domain + Application | Domain unit tests (rare, extracted rules) + Application acceptance tests (mocks on output gateways, in-memory fakes) | | `<Context>.I