MCAF: Testing
Trigger On
- implementing a feature or bugfix
- adding a regression test for a failure
- protecting a refactor with automated verification
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
- repo-wide delivery policy with no test change
- documentation-only changes unless they alter executable verification
Inputs
- the nearest
AGENTS.md
- the changed behaviour and touched boundaries
- existing tests near the impacted code path
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
- Read the repo’s real verification commands from
AGENTS.md.
- Start with a failing test first when the change adds behaviour or fixes a bug.
- Start with the smallest meaningful test scope:
- new or changed tests
- related suite
- broader regressions
- When the stack is .NET, use
mcaf-dotnet as the orchestration skill when the task spans code, tests, and verification, and route framework mechanics through exactly one matching skill:
mcaf-dotnet-xunit
mcaf-dotnet-tunit
mcaf-dotnet-mstest
- Prefer integration, API, or UI coverage when behaviour crosses boundaries.
- Prove the user flow or caller-visible system flow, not just internal details.
- Add a regression test for every bug that can be captured reliably.
- If the stack is .NET and production code changed, do not stop at tests only. Finish with the repo-defined format and analyzer pass as well.
- Use deeper testing references only when the repo’s current strategy is unclear.
Deliver
- automated tests close to the changed behaviour
- verification results that match the repo’s real commands
Validate
- the new behaviour is covered at the right level
- the main user flow or caller-visible system flow is proven
- tests assert meaningful outcomes, not implementation trivia
- coverage expectations from
AGENTS.md are met, or the exception is documented
- the verification sequence matches
AGENTS.md
- for .NET changes, tests were not treated as a substitute for formatting or analyzer gates
- broader suites are run after there is something real to verify
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/test-planning.md first
- open
references/automated-testing.md for deeper strategy and trade-offs
- for broader .NET implementation flow, use
mcaf-dotnet
- for .NET framework-specific mechanics, use exactly one of
mcaf-dotnet-xunit, mcaf-dotnet-tunit, or mcaf-dotnet-mstest
Example Requests
- "Add tests for this bugfix."
- "Protect this refactor with regression coverage."
- "Choose the right test level for this API change."
1---2name: mcaf-testing3description: Add or update automated tests for a change using the repository’s verification rules in `AGENTS.md`. Use when implementing a feature, bugfix, refactor, or regression test; prefer stable integration/API/UI coverage and pull deeper test strategy from the bundled references.4---56# MCAF: Testing78## Trigger On910- implementing a feature or bugfix11- adding a regression test for a failure12- protecting a refactor with automated verification1314## 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- repo-wide delivery policy with no test change23- documentation-only changes unless they alter executable verification2425## Inputs2627- the nearest `AGENTS.md`28- the changed behaviour and touched boundaries29- existing tests near the impacted code path3031## Quick Start32331. Read the nearest `AGENTS.md` and confirm scope and constraints.342. Run this skill's `Workflow` through the `Ralph Loop` until outcomes are acceptable.353. Return the `Required Result Format` with concrete artifacts and verification evidence.3637## Workflow38391. Read the repo’s real verification commands from `AGENTS.md`.402. Start with a failing test first when the change adds behaviour or fixes a bug.413. Start with the smallest meaningful test scope:42 - new or changed tests43 - related suite44 - broader regressions454. When the stack is .NET, use `mcaf-dotnet` as the orchestration skill when the task spans code, tests, and verification, and route framework mechanics through exactly one matching skill:46 - `mcaf-dotnet-xunit`47 - `mcaf-dotnet-tunit`48 - `mcaf-dotnet-mstest`495. Prefer integration, API, or UI coverage when behaviour crosses boundaries.506. Prove the user flow or caller-visible system flow, not just internal details.517. Add a regression test for every bug that can be captured reliably.528. If the stack is .NET and production code changed, do not stop at tests only. Finish with the repo-defined format and analyzer pass as well.539. Use deeper testing references only when the repo’s current strategy is unclear.5455## Deliver5657- automated tests close to the changed behaviour58- verification results that match the repo’s real commands5960## Validate6162- the new behaviour is covered at the right level63- the main user flow or caller-visible system flow is proven64- tests assert meaningful outcomes, not implementation trivia65- coverage expectations from `AGENTS.md` are met, or the exception is documented66- the verification sequence matches `AGENTS.md`67- for .NET changes, tests were not treated as a substitute for formatting or analyzer gates68- broader suites are run after there is something real to verify6970## Ralph Loop7172Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.73741. Plan first (mandatory):75 - analyze current state76 - define target outcome, constraints, and risks77 - write a detailed execution plan78 - list final validation skills to run at the end, with order and reason792. Execute one planned step and produce a concrete delta.803. Review the result and capture findings with actionable next fixes.814. Apply fixes in small batches and rerun the relevant checks or review steps.825. Update the plan after each iteration.836. Repeat until outcomes are acceptable or only explicit exceptions remain.847. If a dependency is missing, bootstrap it or return `status: not_applicable` with explicit reason and fallback path.8586### Required Result Format8788- `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked`89- `plan`: concise plan and current iteration step90- `actions_taken`: concrete changes made91- `validation_skills`: final skills run, or skipped with reasons92- `verification`: commands, checks, or review evidence summary93- `remaining`: top unresolved items or `none`9495For setup-only requests with no execution, return `status: configured` and exact next commands.9697## Load References9899- read `references/test-planning.md` first100- open `references/automated-testing.md` for deeper strategy and trade-offs101- for broader .NET implementation flow, use `mcaf-dotnet`102- for .NET framework-specific mechanics, use exactly one of `mcaf-dotnet-xunit`, `mcaf-dotnet-tunit`, or `mcaf-dotnet-mstest`103104## Example Requests105106- "Add tests for this bugfix."107- "Protect this refactor with regression coverage."108- "Choose the right test level for this API change."