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), ParallelLimiter, 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 - 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.
2. Fix isolation bugs instead of globally serializing the suite unless the repo already documented a justified exception.
3. Run the narrowest useful scope first with dotnet test ... -- --treenode-filter "...". Keep TUnit arguments after --.
4. Capture useful failure evidence: host log dumps, focused console output, coverage files, and Playwright screenshots/HTML for UI tests.
5. 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
• shared distributed fixtures use SharedType.PerTestSession or an equivalent reuse pattern
• shared state is isolated or explicitly controlled
• 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