Code Testing Generation Skill
An AI-powered skill that generates comprehensive, workable unit tests for any programming language using a coordinated multi-agent pipeline.
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
When Not to Use
- Running or executing existing tests (use the
run-tests skill)
- Migrating between test frameworks (use migration skills)
- Writing tests specifically for MSTest patterns (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 from unit-test-generation.prompt.md. This prompt provides best practices for discovering conventions, parameterization strategies, coverage goals (aim for 80%), and language-specific patterns.
Step 2: Invoke the Test Generator
Start by calling the code-testing-generator agent with your test generation request:
Generate unit tests for [path or description of what to test], following the [unit-test-generation.prompt.md](unit-test-generation.prompt.md) guidelines
The Test Generator will manage the entire pipeline automatically.
Step 3: Research Phase (Automatic)
The code-testing-researcher agent analyzes your codebase to understand:
- Language & Framework: Detects C#, TypeScript, Python, Go, Rust, Java, etc.
- Testing Framework: Identifies MSTest, xUnit, Jest, pytest, go test, etc.
- Project Structure: Maps source files, existing tests, and dependencies
- Build Commands: Discovers how to build and test the project
Output: .testagent/research.md
Step 4: Planning Phase (Automatic)
The code-testing-planner agent creates a structured implementation plan:
- Groups files into logical phases (2-5 phases typical)
- Prioritizes by complexity and dependencies
- Specifies test cases for each file
- Defines success criteria per phase
Output: .testagent/plan.md
Step 5: Implementation Phase (Automatic)
The code-testing-implementer agent executes each phase sequentially:
- Read source files to understand the API
- Write test files following project patterns
- Build using the
code-testing-builder sub-agent to verify compilation
- Test using the
code-testing-tester sub-agent to verify tests pass
- Fix using the
code-testing-fixer sub-agent if errors occur
- Lint using the
code-testing-linter sub-agent for code formatting
Each phase completes before the next begins, ensuring incremental progress.
Coverage Types
- Happy path: Valid inputs produce expected outputs
- Edge cases: Empty values, boundaries, special characters
- Error cases: Invalid inputs, null handling, exceptions
State Management
All pipeline state is stored in .testagent/ folder:
| File |
Purpose |
.testagent/research.md |
Codebase analysis results |
.testagent/plan.md |
Phased implementation plan |
.testagent/status.md |
Progress tracking (optional) |
Examples
Strategy Selection
The generator picks a strategy based on request scope:
| User Request |
Strategy |
Why |
"Generate tests for src/services/UserService.ts" |
Direct |
Single file, small scope — write tests immediately, skip sub-agents |
| "Add unit tests for my billing project" |
Single pass |
Moderate scope — one Research → Plan → Implement cycle covers it |
| "Achieve 80% coverage across the entire solution" |
Iterative |
Large scope — multiple R→P→I cycles, each narrowing remaining gaps |
Pipeline Walkthrough
Given a request like "Generate unit tests for my InvoiceService", the pipeline produces:
- Research →
.testagent/research.md containing detected language/framework, build commands, files to test ranked by priority, and existing test inventory
- Plan →
.testagent/plan.md containing phased approach with specific methods and test scenarios (happy path, edge cases, error cases) for each file
- Implement → Test files written, built, and verified per phase. Fix cycle runs automatically if build/test errors occur
- Validate → Full workspace build + full test run to catch cross-project issues
- Report → Summary of tests created, pass/fail counts, coverage notes, and next steps
Language-Specific Examples
The code-testing-extensions skill provides concrete, filled-in examples for each pipeline phase showing real source code, real research output, real plans, and real generated tests. Call the code-testing-extensions skill to discover available extension files, then read:
dotnet-examples.md — MSTest example with InvoiceService: research output, plan output, generated test file, fix cycle walkthrough, and final report
python-examples.md — pytest example with the same InvoiceService scenario: research, plan, generated test file (parametrized, unittest.mock), fix cycles (ModuleNotFoundError, patch target, Mock(spec=...)), and final report
typescript-examples.md — Vitest example (also applicable to Jest) showing it.each parameterization, async tests, fake timers, and ESM/CJS fix cycles
go-examples.md — Standard testing package example with table-driven subtests, hand-written fake repository, injected clock, and -run regex fix cycle
java-examples.md — JUnit 5 + Mockito example on Maven showing @ExtendWith(MockitoExtension.class), @ParameterizedTest + @CsvSource, Clock.fixed(...) for time, and Surefire fix cycles
For languages without a dedicated examples file (Rust, Ruby, Swift, Kotlin, C++, PowerShell), use the base extension file (<language>.md) plus the example file for the closest paradigm — the pipeline shape (research → plan → generate → fix) and the categories of decisions (test layout, mocking strategy, fixed clock for time-dependent code, parameterization style) translate directly.
Agent Reference
| Agent |
Purpose |
code-testing-generator |
Coordinates pipeline |
code-testing-researcher |
Analyzes codebase |
code-testing-planner |
Creates test plan |
code-testing-implementer |
Writes test files |
code-testing-builder |
Compiles code |
code-testing-tester |
Runs tests |
code-testing-fixer |
Fixes errors |
code-testing-linter |
Formats code |
Requirements
- Project must have a build/test system configured
- Testing framework should be installed (or installable)
- VS Code with GitHub Copilot extension
Troubleshooting
Tests don't compile
The code-testing-fixer agent will attempt to resolve compilation errors. Check .testagent/plan.md for the expected test structure. Call the code-testing-extensions skill and read the language-specific extension file for error code references (e.g., dotnet.md for .NET).
Tests fail
Most failures in generated tests are caused by wrong expected values in assertions, not production code bugs:
- Read the actual test output
- Read the production code to understand correct behavior
- Fix the assertion, not the production code
- Never mark tests
[Ignore] or [Skip] just to make them pass
Wrong testing framework detected
Specify your preferred framework in the initial request: "Generate Jest tests for..."
Environment-dependent tests fail
Tests that depend on external services, network endpoints, specific ports, or precise timing will fail in CI environments. Focus on unit tests with mocked dependencies instead.
Build fails on full solution
During phase implementation, build only the specific test project for speed. After all phases, run a full non-incremental workspace build to catch cross-project errors.
1---2name: code-testing-agent3description: Generates and writes new unit tests for any programming language — scaffolds .NET test projects, pytest suites, Vitest/Jest suites, Go test files, and JUnit suites, and configures coverage tooling (coverlet, pytest-cov, @vitest/coverage-v8) as part of test generation. Use when asked to generate tests, generate pytest tests, generate Vitest tests, write unit tests, add tests, improve coverage, comprehensive tests, or scaffold a new test project or suite for an app, service, library, REST API, blueprint, or package — including project-wide, multi-file test generation across services, repositories, routes, and modules. Supports C#/.NET, Python (pytest, Flask/Django), TypeScript/JavaScript (Vitest, Jest, Mocha), Go, Rust, Java (JUnit). Runs a research, planning, and implementation pipeline so tests compile and pass. DO NOT USE FOR: running existing tests (use run-tests); analyzing existing coverage reports (use coverage-analysis or crap-score); MSTest modernization (use writing-mstest-tests).4license: MIT5---67# Code Testing Generation Skill89An AI-powered skill that generates comprehensive, workable unit tests for any programming language using a coordinated multi-agent pipeline.1011## When to Use This Skill1213Use this skill when you need to:1415- Generate unit tests for an entire project or specific files16- Improve test coverage for existing codebases17- Create test files that follow project conventions18- Write tests that actually compile and pass19- Add tests for new features or untested code2021## When Not to Use2223- Running or executing existing tests (use the `run-tests` skill)24- Migrating between test frameworks (use migration skills)25- Writing tests specifically for MSTest patterns (use `writing-mstest-tests`)26- Debugging failing test logic2728## How It Works2930This skill coordinates multiple specialized agents in a **Research → Plan → Implement** pipeline:3132### Pipeline Overview3334```text35┌─────────────────────────────────────────────────────────────┐36│ TEST GENERATOR │37│ Coordinates the full pipeline and manages state │38└─────────────────────┬───────────────────────────────────────┘39 │40 ┌─────────────┼─────────────┐41 ▼ ▼ ▼42┌───────────┐ ┌───────────┐ ┌───────────────┐43│ RESEARCHER│ │ PLANNER │ │ IMPLEMENTER │44│ │ │ │ │ │45│ Analyzes │ │ Creates │ │ Writes tests │46│ codebase │→ │ phased │→ │ per phase │47│ │ │ plan │ │ │48└───────────┘ └───────────┘ └───────┬───────┘49 │50 ┌─────────┬───────┼───────────┐51 ▼ ▼ ▼ ▼52 ┌─────────┐ ┌───────┐ ┌───────┐ ┌───────┐53 │ BUILDER │ │TESTER │ │ FIXER │ │LINTER │54 │ │ │ │ │ │ │ │55 │ Compiles│ │ Runs │ │ Fixes │ │Formats│56 │ code │ │ tests │ │ errors│ │ code │57 └─────────┘ └───────┘ └───────┘ └───────┘58```5960## Step-by-Step Instructions6162### Step 1: Determine the user request6364Make sure you understand what user is asking and for what scope.65When the user does not express strong requirements for test style, coverage goals, or conventions, source the guidelines from [unit-test-generation.prompt.md](unit-test-generation.prompt.md). This prompt provides best practices for discovering conventions, parameterization strategies, coverage goals (aim for 80%), and language-specific patterns.6667### Step 2: Invoke the Test Generator6869Start by calling the `code-testing-generator` agent with your test generation request:7071```text72Generate unit tests for [path or description of what to test], following the [unit-test-generation.prompt.md](unit-test-generation.prompt.md) guidelines73```7475The Test Generator will manage the entire pipeline automatically.7677### Step 3: Research Phase (Automatic)7879The `code-testing-researcher` agent analyzes your codebase to understand:8081- **Language & Framework**: Detects C#, TypeScript, Python, Go, Rust, Java, etc.82- **Testing Framework**: Identifies MSTest, xUnit, Jest, pytest, go test, etc.83- **Project Structure**: Maps source files, existing tests, and dependencies84- **Build Commands**: Discovers how to build and test the project8586Output: `.testagent/research.md`8788### Step 4: Planning Phase (Automatic)8990The `code-testing-planner` agent creates a structured implementation plan:9192- Groups files into logical phases (2-5 phases typical)93- Prioritizes by complexity and dependencies94- Specifies test cases for each file95- Defines success criteria per phase9697Output: `.testagent/plan.md`9899### Step 5: Implementation Phase (Automatic)100101The `code-testing-implementer` agent executes each phase sequentially:1021031. **Read** source files to understand the API1042. **Write** test files following project patterns1053. **Build** using the `code-testing-builder` sub-agent to verify compilation1064. **Test** using the `code-testing-tester` sub-agent to verify tests pass1075. **Fix** using the `code-testing-fixer` sub-agent if errors occur1086. **Lint** using the `code-testing-linter` sub-agent for code formatting109110Each phase completes before the next begins, ensuring incremental progress.111112### Coverage Types113114- **Happy path**: Valid inputs produce expected outputs115- **Edge cases**: Empty values, boundaries, special characters116- **Error cases**: Invalid inputs, null handling, exceptions117118## State Management119120All pipeline state is stored in `.testagent/` folder:121122| File | Purpose |123| ------------------------ | ---------------------------- |124| `.testagent/research.md` | Codebase analysis results |125| `.testagent/plan.md` | Phased implementation plan |126| `.testagent/status.md` | Progress tracking (optional) |127128## Examples129130### Strategy Selection131132The generator picks a strategy based on request scope:133134| User Request | Strategy | Why |135|---|---|---|136| "Generate tests for `src/services/UserService.ts`" | **Direct** | Single file, small scope — write tests immediately, skip sub-agents |137| "Add unit tests for my billing project" | **Single pass** | Moderate scope — one Research → Plan → Implement cycle covers it |138| "Achieve 80% coverage across the entire solution" | **Iterative** | Large scope — multiple R→P→I cycles, each narrowing remaining gaps |139140### Pipeline Walkthrough141142Given a request like *"Generate unit tests for my InvoiceService"*, the pipeline produces:1431441. **Research** → `.testagent/research.md` containing detected language/framework, build commands, files to test ranked by priority, and existing test inventory1452. **Plan** → `.testagent/plan.md` containing phased approach with specific methods and test scenarios (happy path, edge cases, error cases) for each file1463. **Implement** → Test files written, built, and verified per phase. Fix cycle runs automatically if build/test errors occur1474. **Validate** → Full workspace build + full test run to catch cross-project issues1485. **Report** → Summary of tests created, pass/fail counts, coverage notes, and next steps149150### Language-Specific Examples151152The `code-testing-extensions` skill provides concrete, filled-in examples for each pipeline phase showing real source code, real research output, real plans, and real generated tests. Call the `code-testing-extensions` skill to discover available extension files, then read:153154- **`dotnet-examples.md`** — MSTest example with InvoiceService: research output, plan output, generated test file, fix cycle walkthrough, and final report155- **`python-examples.md`** — pytest example with the same InvoiceService scenario: research, plan, generated test file (parametrized, `unittest.mock`), fix cycles (`ModuleNotFoundError`, patch target, `Mock(spec=...)`), and final report156- **`typescript-examples.md`** — Vitest example (also applicable to Jest) showing `it.each` parameterization, async tests, fake timers, and ESM/CJS fix cycles157- **`go-examples.md`** — Standard `testing` package example with table-driven subtests, hand-written fake repository, injected clock, and `-run` regex fix cycle158- **`java-examples.md`** — JUnit 5 + Mockito example on Maven showing `@ExtendWith(MockitoExtension.class)`, `@ParameterizedTest` + `@CsvSource`, `Clock.fixed(...)` for time, and Surefire fix cycles159160For languages without a dedicated examples file (Rust, Ruby, Swift, Kotlin, C++, PowerShell), use the base extension file (`<language>.md`) plus the example file for the closest paradigm — the pipeline shape (research → plan → generate → fix) and the categories of decisions (test layout, mocking strategy, fixed clock for time-dependent code, parameterization style) translate directly.161162## Agent Reference163164| Agent | Purpose |165| -------------------------- | -------------------- |166| `code-testing-generator` | Coordinates pipeline |167| `code-testing-researcher` | Analyzes codebase |168| `code-testing-planner` | Creates test plan |169| `code-testing-implementer` | Writes test files |170| `code-testing-builder` | Compiles code |171| `code-testing-tester` | Runs tests |172| `code-testing-fixer` | Fixes errors |173| `code-testing-linter` | Formats code |174175## Requirements176177- Project must have a build/test system configured178- Testing framework should be installed (or installable)179- VS Code with GitHub Copilot extension180181## Troubleshooting182183### Tests don't compile184185The `code-testing-fixer` agent will attempt to resolve compilation errors. Check `.testagent/plan.md` for the expected test structure. Call the `code-testing-extensions` skill and read the language-specific extension file for error code references (e.g., `dotnet.md` for .NET).186187### Tests fail188189Most failures in generated tests are caused by **wrong expected values in assertions**, not production code bugs:1901911. Read the actual test output1922. Read the production code to understand correct behavior1933. Fix the assertion, not the production code1944. Never mark tests `[Ignore]` or `[Skip]` just to make them pass195196### Wrong testing framework detected197198Specify your preferred framework in the initial request: "Generate Jest tests for..."199200### Environment-dependent tests fail201202Tests that depend on external services, network endpoints, specific ports, or precise timing will fail in CI environments. Focus on unit tests with mocked dependencies instead.203204### Build fails on full solution205206During phase implementation, build only the specific test project for speed. After all phases, run a full non-incremental workspace build to catch cross-project errors.