Dotnet Testing Strategy

This is the strategic layer before you write any tests. It gives you a decision tree for unit versus integration versus E2E, concrete criteria like "pure logic gets unit tests, repository queries get integration tests with real databases," and naming conventions that mirror your source structure. The test doubles section clarifies when to use mocks versus fakes versus stubs with actual behavioral differences, not just definitions. Most useful when you inherit a codebase with inconsistent test patterns or when you're starting a new project and want to avoid the "we have 500 integration tests and they take 20 minutes to run" problem. Pairs with dotnet-add-testing for scaffolding and dotnet-integration-testing for the actual patterns.