mcaf-testing

Add or update automated tests for a change (bugfix, feature, refactor) using the repository’s testing rules in `AGENTS.md`. Use TDD where applicable; derive scenarios from docs/Features/* and ADR inva

SKILL.md

GitHub

MCAF: Testing

Follow root and applicable local AGENTS.md for scope, test commands, runner, coverage policy, and required gates.

Workflow

  1. Inspect the implementation, callers, contracts, existing tests, fixtures, and accepted behavior before designing tests. Under MCAF-REQ-001, map non-trivial feature tests to REQ-*/AC-* and update their evidence matrix.
  2. Keep tests in the owning canonical slice under MCAF-ARCH-001. Choose the level that proves the real flow: isolated logic, integration, API, or rendered UI.
  3. Design regressions from requirements before implementation. They must detect the original defect and assert meaningful caller-visible results, required rejection paths, side effects, state transitions, and edge cases.
  4. Implement the complete approved code and test scope, then review both before execution. Check fixtures, isolation, cleanup, assertion strength, and whether incorrect behavior would actually fail the test.
  5. Use real dependencies, containers, test instances, or sandboxes as required by repository policy. Do not substitute doubles or lower expectations to hide broken behavior.
  6. After self-review, fixes, and formatting, execute one planned verification phase with focused tests and required broader gates. A separate red-phase or baseline run needs a concrete purpose or explicit requirement. Fix the complete cause of failures before rerunning affected checks.
  7. Report commands and observed results, coverage gaps, and exact blockers. Passing focused tests does not imply a broader suite or deployment passed.

For .NET, identify VSTest versus Microsoft.Testing.Platform from the actual repo configuration. Use its installed matching framework skill and exact commands; do not copy arguments from another runner.

References