/code-testing

name: code-testing
description: >-
  ALWAYS USE for test work that requires changes: write, add, generate, repair,
  or strengthen tests for existing code in xUnit, MSTest, NUnit, pytest,
  Vitest/Jest, Go, or another framework. Includes regression cases, failing or
  flaky tests, coverage-driven additions, and audit-then-fix requests. Focused
  work stays direct; broad or multi-stage work invokes test-engineer. DO NOT USE
  for only running tests, analysis-only audits, framework/platform migrations,
  a test blocked on a missing production seam (testability-obstacle), or MSTest
  API/configuration corrections that do not design new cases
  (writing-mstest-tests). Within an active test-engineer pipeline, reuse supplied
  guidance and do not re-enter this skill.
license: MIT

Code Testing Skill

The reliable implicit entry point for generating, repairing, and strengthening tests. It handles focused work directly and invokes the public `test-engineer` agent for broad or multi-stage requests.

Non-negotiable execution contract

**Check pipeline ownership first.** If the active agent is `test-engineer` (including a plugin-qualified name such as `dotnet-test:test-engineer`), or the caller assigned you a phase of that pipeline, do not delegate to another generator. Continue the assigned work inline. This guard takes precedence over every broad-scope delegation instruction below, even if this skill was loaded automatically.

Classify scope **before editing**:

• **Broad** (a project/package-wide suite, or multiple production

files/modules): create `research.md` and `plan.md` in a resolved non-stageable `<TESTAGENT_DIR>` before implementation, then `status.md` there after the final test-quality review. When `test-engineer` is available, invoke that named custom agent before implementing; do not replace it with a generic subagent carrying the same label or implement the broad request inline. If the state files are absent, the broad workflow is incomplete.

• **Focused** (the user explicitly limits work to one function/class/file or one

missing method): do not create intermediate state files or fan out to multiple agents. A sparse project-wide request remains broad even when only one source module is present.

For either scope, run the narrowest relevant test command to a clean exit. Always apply [Report-safe test names and result validation](unit-test-generation.prompt.md#report-safe-test-names-and-result-validation), including when the caller supplies conventions. Pass this contract to delegated implementers/testers; preserve edge-case data and validate configured reports, not just console output. Keep the handoff proportional: for one to three focused requirements, use a compact bullet list under a **Requirement coverage** label that names the tests and successful command; for broader or multi-requirement work, use a `Requirement | Evidence` table. Each requested behavior must cite an exact test name.

Before sending a broad-scope final response, check that the response itself contains `| Requirement | Evidence |` and exact test names for every behavioral row. A table in a child report or internal plan is not enough. Do not summarize away those names into module-level bullets or an `Area | Tests` table.

Intermediate state files are internal working data, never deliverables. Keep `<TESTAGENT_DIR>` non-stageable, never place it or its files in version-controlled workspace content, and never modify `.gitignore` to hide them.

Treat completeness as a requirement matrix, not a test-count target. Give every independently requested state, boundary, error path, or interaction its own concrete assertion. Combine cases only when one execution genuinely proves the whole requested combination; do not let a parameterized happy-path case stand in for an empty state, invalid discriminator, or before/at/after boundary. For broad requests that name several production modules or layers, give each named module direct tests for its non-trivial public behavior. Cross-module tests prove composition, but do not substitute for the requested module-level coverage. Judge breadth by the behavior matrix, never by matching or exceeding a raw test count.

At the public entry point, delegate broad work to `test-engineer` once. Research, plan, implementation, and review remain required, but they need not be separate sub-agent calls.

Use only capabilities available in the current runtime. Do not retry a missing skill under aliases or use another agent to retry a policy-denied operation. Read language guidance directly from the caller-provided or runtime-listed `code-testing-extensions` catalog and its matching language file. It is reference-only, not an invocable skill. If the bundle is absent, use manifests and representative tests and report the missing reference rather than searching installation dirs. If scratch storage is denied, keep the research and plan in context, continue permitted test edits, and report the missing state artifacts. If execution is denied, continue permitted static review and report tests as unrun, never passed. Neither blocker authorizes modifying production code or weakening requirements.

For a **broad or comprehensive** request, the explicit matrix is the floor, not the ceiling. Treat each requested module or layer as an inventory heading, not one behavior: expand it into the bounded public operations and their distinct validation paths, branches, boundaries, interactions, and state transitions. After satisfying the explicit matrix, inspect each target API for observable equivalence partitions and invariants that the prompt did not name: identity, empty, singleton and representative interior inputs; exact boundaries plus an immediately adjacent value; invalid partitions; and ordering, monotonicity, rollover, capacity, truncation, or state invariants implied by the implementation. Add one mutation-relevant case per distinct partition not already proved, using para