write-unit-testslisted

## When to use Reach for this when writing **isolated unit tests** — fast tests that mock every dependency (DB, buses, external services) and never boot the app. Use it for CQRS command/query/event handlers, service classes, and request-DTO validation, or to stand up the unit-test harness in a new service. **Two test layers — don't confuse them:** | Layer | Boots app? | DB | Use for | Doc | |---|---|---|---|---| | **Unit** (this doc) | no | all mocked | handler/service/DTO logic in isolation, fast | here | | **Integration / e2e** | yes | real test DB | the use-case through the real transport/HTTP boundary | [write-service-code](./write-service-code.md) §8 | A repo runs one or both (two jest projects — see below). **Follow your repo's established setup:** some repos test integration-only (the global *HTTP-layer testing rule* — skip a unit test if an integration test already pins the contract); others keep a full unit layer. Don't bolt a unit layer onto an integration-only repo (or vice versa) without agreeing it with the team. Examples use a neutral `listing` domain; `<Module>`/`<Entity>` are placeholders. ## Steps ### 1. Layout & file naming ``` test/unit/ test-utils.ts # all mock factory functions (§3) helpers/ validate-dto.ts # flattenValidationErrors helper (§4, Pattern 3) factories/ index.ts # re-exports every builder (one-line imports) listing.factory.ts # buildListing, buildListingWith