TUnit

Trigger On

• the repo uses TUnit
• you need to add, run, debug, or repair TUnit tests
• the repo uses Microsoft.Testing.Platform-based test execution
• the repo uses ClassDataSource<...>(Shared = SharedType.PerTestSession), TUnit.Playwright, or --treenode-filter

Workflow

1. Confirm the project really uses TUnit and not a different MTP-based framework.
2. Read the repo's real test command from AGENTS.md. If the repo has no explicit command yet, start with dotnet test PROJECT_OR_SOLUTION.
3. Keep the TUnit execution model intact:

- tests are source-generated at build time - tests run in parallel by default - on .NET 10, test modules also run in parallel by default up to Environment.ProcessorCount - built-in analyzers should remain enabled

1. Choose the fixture level deliberately:

- plain TUnit tests for isolated logic - shared AppHost/Aspire fixtures for HTTP, SignalR, SSE, or UI flows - WebApplicationFactory layered over shared Aspire infra when tests need Host DI services, IGrainFactory, or other runtime internals

1. Reuse expensive fixtures with ClassDataSource<Fixture>(Shared = SharedType.PerTestSession) instead of booting distributed infrastructure per test. Fixture reuse does not serialize consumers: keep the fixture concurrency-safe and give each test unique mutable state.
2. Keep tests and test modules parallel. Do not add --max-parallel-test-modules 1, TUNIT_MAX_PARALLEL_TESTS=1, [assembly: NotInParallel], a class-wide [NotInParallel], or an equivalent global restriction.
3. Use keyed [NotInParallel("collision-domain")] only on the smallest tests that perform destructive changes to the same shared state and can corrupt one another. A shared read-only fixture, expensive startup, module boundary, or vague CI-stability concern is not a reason to limit parallelism.
4. Run the narrowest useful scope first with dotnet test ... --treenode-filter "..." on .NET 10. Use the older -- separator only when the repository is pinned to an SDK that requires it.
5. Capture useful failure evidence: host log dumps, focused console output, coverage files, and Playwright screenshots/HTML for UI tests.
6. Use [Test], [Arguments], hooks, and dependencies only when they make the scenario clearer, not because the framework allows it.

Deliver

• TUnit tests that respect source generation and parallel execution
• commands that work in local and CI runs
• framework-specific verification guidance for the repo
• a fixture strategy that matches the actual test scope: logic-only, AppHost/API, Host DI/grains, or Playwright UI

Validate

• the command matches the repo's TUnit runner style
• focused runs use --treenode-filter rather than VSTest-style --filter
• .NET 10 runs pass MTP options directly without a -- separator
• no global or assembly-wide single-thread setting has been introduced
• any keyed non-parallel group is limited to tests with a named destructive shared-state collision
• shared distributed fixtures use SharedType.PerTestSession or an equivalent reuse pattern
• fixture and shared infrastructure are safe for concurrent consumers; mutable data is isolated per test
• built-in TUnit analyzers remain active
• coverage tooling matches Microsoft.Testing.Platform if coverage is enabled
• UI failures capture artifacts and server-side failures expose enough logs to avoid blind reruns

Load References

Related skills