MCAF: .NET 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
Value
- produce a concrete project delta: code, docs, config, tests, CI, or review artifact
- reduce ambiguity through explicit planning, verification, and final validation skills
- leave reusable project context so future tasks are faster and safer
Do Not Use For
- xUnit projects
- MSTest projects
- generic test strategy with no TUnit-specific mechanics
Inputs
- the nearest
AGENTS.md
- the test project file and package references
- the repo's current TUnit execution command
Quick Start
- Read the nearest
AGENTS.md and confirm scope and constraints.
- Run this skill's
Workflow through the Ralph Loop until outcomes are acceptable.
- Return the
Required Result Format with concrete artifacts and verification evidence.
Workflow
- Confirm the project really uses TUnit and not a different MTP-based framework.
- 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.
- 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
- Fix isolation bugs instead of globally serializing the suite unless the repo already documented a justified exception.
- Run the narrowest useful scope first. If the repo hasn't documented filter switches for TUnit yet, prefer project-level focused runs over guessed runner arguments.
- Use
[Test], [Arguments], hooks, and dependencies only when they make the scenario clearer, not because the framework allows it.
Bootstrap When Missing
If TUnit is requested but not configured yet:
- Detect current state:
rg -n "TUnit|Microsoft\\.Testing\\.Platform" -g '*.csproj' -g 'Directory.Build.*' .
- Add the minimal package set to the test project:
dotnet add TEST_PROJECT.csproj package TUnit
dotnet add TEST_PROJECT.csproj package Microsoft.NET.Test.Sdk
- Keep the runner model explicit in
AGENTS.md and CI:
- record that the repo uses Microsoft.Testing.Platform-compatible execution for this test project
- record the exact
dotnet test TEST_PROJECT.csproj command the repo will use
- Add one small executable test using
[Test].
- Run
dotnet test TEST_PROJECT.csproj and return status: configured or status: improved.
- If the repo intentionally standardizes on xUnit or MSTest, return
status: not_applicable unless migration is explicitly requested.
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
Validate
- the command matches the repo's TUnit runner style
- shared state is isolated or explicitly controlled
- built-in TUnit analyzers remain active
- coverage tooling matches Microsoft.Testing.Platform if coverage is enabled
Ralph Loop
Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.
- Plan first (mandatory):
- analyze current state
- define target outcome, constraints, and risks
- write a detailed execution plan
- list final validation skills to run at the end, with order and reason
- Execute one planned step and produce a concrete delta.
- Review the result and capture findings with actionable next fixes.
- Apply fixes in small batches and rerun the relevant checks or review steps.
- Update the plan after each iteration.
- Repeat until outcomes are acceptable or only explicit exceptions remain.
- If a dependency is missing, bootstrap it or return
status: not_applicable with explicit reason and fallback path.
Required Result Format
status: complete | clean | improved | configured | not_applicable | blocked
plan: concise plan and current iteration step
actions_taken: concrete changes made
validation_skills: final skills run, or skipped with reasons
verification: commands, checks, or review evidence summary
remaining: top unresolved items or none
For setup-only requests with no execution, return status: configured and exact next commands.
Load References
- read
references/tunit.md first
Example Requests
- "Run this TUnit project correctly."
- "Fix our TUnit CI command."
- "Add a regression test in TUnit without breaking parallelism."
1---2name: mcaf-dotnet-tunit3description: Write, run, or repair .NET tests that use TUnit. Use when a repo uses `TUnit`, `[Test]`, `[Arguments]`, source-generated test projects, or Microsoft.Testing.Platform-based execution.4---56# MCAF: .NET TUnit78## Trigger On910- the repo uses TUnit11- you need to add, run, debug, or repair TUnit tests12- the repo uses Microsoft.Testing.Platform-based test execution1314## Value1516- produce a concrete project delta: code, docs, config, tests, CI, or review artifact17- reduce ambiguity through explicit planning, verification, and final validation skills18- leave reusable project context so future tasks are faster and safer1920## Do Not Use For2122- xUnit projects23- MSTest projects24- generic test strategy with no TUnit-specific mechanics2526## Inputs2728- the nearest `AGENTS.md`29- the test project file and package references30- the repo's current TUnit execution command3132## Quick Start33341. Read the nearest `AGENTS.md` and confirm scope and constraints.352. Run this skill's `Workflow` through the `Ralph Loop` until outcomes are acceptable.363. Return the `Required Result Format` with concrete artifacts and verification evidence.3738## Workflow39401. Confirm the project really uses TUnit and not a different MTP-based framework.412. 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`.423. Keep the TUnit execution model intact:43 - tests are source-generated at build time44 - tests run in parallel by default45 - built-in analyzers should remain enabled464. Fix isolation bugs instead of globally serializing the suite unless the repo already documented a justified exception.475. Run the narrowest useful scope first. If the repo hasn't documented filter switches for TUnit yet, prefer project-level focused runs over guessed runner arguments.486. Use `[Test]`, `[Arguments]`, hooks, and dependencies only when they make the scenario clearer, not because the framework allows it.4950## Bootstrap When Missing5152If `TUnit` is requested but not configured yet:53541. Detect current state:55 - `rg -n "TUnit|Microsoft\\.Testing\\.Platform" -g '*.csproj' -g 'Directory.Build.*' .`562. Add the minimal package set to the test project:57 - `dotnet add TEST_PROJECT.csproj package TUnit`58 - `dotnet add TEST_PROJECT.csproj package Microsoft.NET.Test.Sdk`593. Keep the runner model explicit in `AGENTS.md` and CI:60 - record that the repo uses Microsoft.Testing.Platform-compatible execution for this test project61 - record the exact `dotnet test TEST_PROJECT.csproj` command the repo will use624. Add one small executable test using `[Test]`.635. Run `dotnet test TEST_PROJECT.csproj` and return `status: configured` or `status: improved`.646. If the repo intentionally standardizes on xUnit or MSTest, return `status: not_applicable` unless migration is explicitly requested.6566## Deliver6768- TUnit tests that respect source generation and parallel execution69- commands that work in local and CI runs70- framework-specific verification guidance for the repo7172## Validate7374- the command matches the repo's TUnit runner style75- shared state is isolated or explicitly controlled76- built-in TUnit analyzers remain active77- coverage tooling matches Microsoft.Testing.Platform if coverage is enabled7879## Ralph Loop8081Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.82831. Plan first (mandatory):84 - analyze current state85 - define target outcome, constraints, and risks86 - write a detailed execution plan87 - list final validation skills to run at the end, with order and reason882. Execute one planned step and produce a concrete delta.893. Review the result and capture findings with actionable next fixes.904. Apply fixes in small batches and rerun the relevant checks or review steps.915. Update the plan after each iteration.926. Repeat until outcomes are acceptable or only explicit exceptions remain.937. If a dependency is missing, bootstrap it or return `status: not_applicable` with explicit reason and fallback path.9495### Required Result Format9697- `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked`98- `plan`: concise plan and current iteration step99- `actions_taken`: concrete changes made100- `validation_skills`: final skills run, or skipped with reasons101- `verification`: commands, checks, or review evidence summary102- `remaining`: top unresolved items or `none`103104For setup-only requests with no execution, return `status: configured` and exact next commands.105106## Load References107108- read `references/tunit.md` first109110## Example Requests111112- "Run this TUnit project correctly."113- "Fix our TUnit CI command."114- "Add a regression test in TUnit without breaking parallelism."