---

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, 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. 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 parameterized or table-driven cases only for siblings that prove the same behavior. A passing coverage threshold is validation, not a breadth stop condition. Stop when remaining inputs exercise the same branch and invariant, not merely when the explicit checklist is complete; never add cases only to raise the count.

When to Use This Skill

Use this skill when you need to:

• Generate unit tests for an entire project or specific files
• Improve test coverage for existing codebases
• Create test files that follow project conventions
• Write tests that actually compile and pass
• Add tests for new features or untested code
• Generate or extend MSTest suites; load writing-mstest-tests as supporting guidance after this entry skill has established scope and project conventions

When Not to Use

• Running or executing existing tests (use the run-tests skill)
• Migrating between test frameworks (use migration skills)
• Answering an MSTest API/pattern or modernization question that does not ask to generate tests (use writing-mstest-tests)
• Analysis-only diagnosis of failing tests when no code or test changes are requested

How It Works

This skill coordinates multiple specialized agents in a Research → Plan → Implement pipeline:

Pipeline Overview

┌─────────────────────────────────────────────────────────────┐
│                     TEST GENERATOR                          │
│  Coordinates the full pipeline and manages state            │
└─────────────────────┬───────────────────────────────────────┘
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
┌───────────┐  ┌───────────┐  ┌───────────────┐
│ RESEARCHER│  │  PLANNER  │  │  IMPLEMENTER  │
│           │  │           │  │               │
│ Analyzes  │  │ Creates   │  │ Writes tests  │
│ codebase  │→ │ phased    │→ │ per phase     │
│           │  │ plan      │  │               │
└───────────┘  └───────────┘  └───────┬───────┘
                                      │
                    ┌─────────┬───────┼───────────┐
                    ▼         ▼       ▼           ▼
              ┌─────────┐ ┌───────┐ ┌───────┐ ┌───────┐
              │ BUILDER │ │TESTER │ │ FIXER │ │LINTER │
              │         │ │       │ │       │ │       │
              │ Compiles│ │ Runs  │ │ Fixes │ │Formats│
              │ code    │ │ tests │ │ errors│ │ code  │
              └─────────┘ └───────┘ └───────┘ └───────┘

Step-by-Step Instructions

Step 1: Determine the user request

Classify both intent and scope before editing:

• Generate or extend: follow the generation workflow below.
• Repair: reproduce the narrow failure, determine whether the defect is in the test or production behavior, make the smallest authorized fix, and rerun the covering command.
• Audit then fix: invoke test-engineer so it can coordinate the internal quality specialist and implementation work.

Make sure you understand what user is asking and for what scope. When the user does not express strong requirements for test style, coverage goals, or conventions, source the guidelines from unit-test-generation.prompt.md. This prompt provides best practices for discovering conventions, parameterization strategies, behavior-focused coverage, and language-specific patterns.

Step 2: Size the request before invoking anything

Match the machinery to the scope. Running the full pipeline on a one-file request costs turns and tool calls without improving the tests.

| Scope | What it looks like | How to run it | | --- | --- | --- | | Focused | One function, class, or file; "tests for X only"; extending an existing suite with the missing cases | Skip intermediate state files and the sub-agent fan-out. Keep the requirement checklist in your head (or in the final table), read only the target and one neighbouring test for conventions, write the tests, run the narrowest test command, review your own assertions inline. | | Broad | A project, package, or module set; "comprehensive suite"; a coverage threshold to clear across several files | Run the full Research → Plan → Implement pipeline in Step 3, with intermediate state files under <TESTAGENT_DIR> and the completion contract below. |

When in doubt, start focused and escalate only if the request turns out to span several files. Escalating costs one extra pass; running the broad pipeline on a focused request costs several.

Before ending a focused request, check all three conditions together:

1. every named behavior has a concrete assertion, including each requested boundary or error path;
2. the narrow test command exited successfully;
3. the final handoff maps those behaviors to exact test names and cites that successful command.

Do not replace requirement-level evidence with a generic list of covered areas.

Step 3: Invoke the Test Generator (broad scope)

Start by invoking the named test-engineer custom agent with your test generation request. Do not use a generic/general-purpose subagent merely named test-engineer:

You are the sole pipeline owner for this request. Do not invoke code-testing or another test-engineer; complete the phases in your current context. Generate unit tests for [path or description of what to test], following the [unit-test-generation.prompt.md](unit-test-generation.prompt.md) guidelines. Treat the current workspace as authoritative even when it is sparse, gutted-looking, synthetic, or missing tracked files; never restore or reconstruct it, including with `git checkout`, `git restore`, `git reset`, or `git clean`.

The Test Generator owns the pipeline. After it returns, consume its recorded quality checks, validation results, and requirement matrix instead of repeating Steps 4 and 5 as another pipeline. Do not reload review skills or rerun unchanged passing commands. Preserve exact test names from its evidence in the final handoff. If evidence is missing, inspect or follow up on that specific gap without restarting generation. A reported capability-wide denial also applies to the caller; do not attempt another command using that capability.

If test-engineer is unavailable, do not skip the workflow. Execute the same Research → Plan → Implement sequence inli