What this prompt does
This prompt sets up a full xUnit testing strategy for a [dotnet_version] [project_type] app. It is structured as eight steps so the model covers the whole pyramid rather than just unit tests: project layout ([test_structure]), unit tests for [unit_test_targets] using [mock_library], integration tests with WebApplicationFactory against [integration_scenarios], collection fixtures for [shared_resources], parameterized Theory tests for [theory_scenarios], custom assertions for [custom_assertions], naming via [naming_convention], and CI wiring with [ci_tool].
The variables control scope and realism. [test_db_approach] decides whether integration tests hit a real database (for example Testcontainers) or an in-memory substitute, which changes how much you can trust them. [shared_resources] and [mock_library] keep the suite fast and consistent, while [naming_convention] makes failures readable. Asking for [example_count] examples per area stops the answer from being abstract and gives you concrete templates to copy. Splitting the work across [test_structure] also signals intent: unit, integration, and architecture tests have different speeds and failure modes, and keeping them in separate projects lets you run the fast ones constantly and the slow ones in CI.
When to use it
- Standing up a test suite from scratch on a new .NET service
- You want integration tests that exercise real database and auth flows, not just mocked happy paths
- Adding collection fixtures so expensive setup like a database container is shared across classes
- Introducing parameterized Theory tests to cover many input combinations cleanly
- You need consistent test naming and folder structure mirroring the source project
- Wiring tests into
[ci_tool]with coverage and parallel execution
Example output
Expect a layered plan with code: a solution structure showing [test_structure], several Arrange-Act-Assert unit tests using [mock_library], a WebApplicationFactory-based integration test class, a collection fixture for [shared_resources], InlineData examples, custom assertion extensions, and a CI config snippet. Each section is short code plus explanation rather than one giant test file.
Pro tips
- Set
[test_db_approach]deliberately — Testcontainers gives real confidence but needs Docker in CI; in-memory is faster but misses provider-specific behavior - Name your real
[unit_test_targets](validators, value objects, services) so the examples match your domain instead of generic calculators - Keep
[mock_library]consistent with your team; mixing NSubstitute and Moq in one suite is a common source of confusion - Use
[naming_convention]like MethodName_StateUnderTest_ExpectedBehavior so a failing test name alone tells you what broke - Push expensive setup into
[shared_resources]collection fixtures; spinning up a container per test class is the usual cause of a slow suite - If parallel execution causes flaky integration tests, ask the model how to isolate the
[test_db_approach]per test or reset state between runs - Reach for Theory and InlineData on
[theory_scenarios]like boundary values; one parameterized method beats ten near-identical copies and keeps the failure output specific to the failing input - Build the custom assertions for
[custom_assertions]early; a clear failure message on a Result<T> or validation collection saves far more debugging time than it costs to write
