/code-testing-agent

name: code-testing-agent
description: >-
  ALWAYS USE whenever asked to write, add, or generate unit tests for existing
  code, including one helper, function, class, or missing regression case as well
  as project-wide suites. Also use for "cover this untested method", scaffolding
  tests where none exist, sparse workspaces, classic packages.config MSTest, and
  extending healthy suites. Focused requests use a proportional direct workflow;
  broad requests use the full pipeline. DO NOT USE for only running/diagnosing
  tests, coverage/audits, a test blocked on a missing production seam
  (testability-obstacle), or correcting supplied MSTest assertions, attributes,
  lifecycle, or configuration without designing new cases (writing-mstest-tests).
license: MIT

Code Testing Generation Skill

An AI-powered skill that generates comprehensive, workable unit tests for any programming language using a coordinated multi-agent pipeline.

Non-negotiable execution contract

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. If these 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 and finish with a compact `Requirement | Evidence` table. Each requested behavior must cite an exact test name; validation rows cite the successful command. For focused work, "no intermediate state files" changes only the process, not the final evidence contract.

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.

For a **broad or comprehensive** request, the explicit matrix is the floor, not the ceiling. After satisfying it, 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 for siblings. 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`)

• Debugging failing test logic

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

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