code-testing

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

这是用于生成、修复和强化测试的可靠隐式入口点。它会直接处理聚焦型工作，对于宽泛或多阶段的请求，则调用公开的

test-engineer

Agent。

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.

首先检查流水线所有权。 如果当前活跃的Agent是

test-engineer

（包括带插件限定的名称，例如

dotnet-test:test-engineer

），或者调用方已为你分配了该流水线的某个阶段，请不要委派给其他生成器。直接继续执行分配的工作。此防护规则优先于下文所有宽泛范围的委派指令，即使本技能是自动加载的也不例外。

在编辑之前先划分范围：

宽泛型（项目/包级别的测试套件，或多个生产文件/模块）：在实现前，先在已解析的不可暂存
```
<TESTAGENT_DIR>
```
中创建
```
research.md
```
和
```
plan.md
```
，在最终测试质量评审后再在该目录下创建
```
status.md
```
。当
```
test-engineer
```
可用时，在实现前调用该命名自定义Agent；不要用带有相同标签的通用子Agent替代它，也不要直接内联实现宽泛请求。如果状态文件不存在，则说明宽泛工作流尚未完成。
聚焦型（用户明确将工作限制在单个函数/类/文件或单个缺失的方法）：不要创建中间状态文件，也不要分派给多个Agent。即使只有一个源模块，稀疏的项目级请求仍属于宽泛型。

无论哪种范围，都要运行最窄范围的相关测试命令直至正常退出。始终遵循报告安全的测试名称与结果验证，即使调用方提供了约定也要遵守。将此契约传递给被委派的实现者/测试人员；保留边界用例数据并验证配置的报告，而不仅仅是控制台输出。

交接内容要与工作量匹配：对于1到3个聚焦型需求，在需求覆盖标签下使用紧凑的项目符号列表，列出测试名称和成功执行的命令；对于更宽泛或多需求的工作，使用

需求 | 证据

表格。每个被请求的行为都必须引用确切的测试名称。

在发送宽泛范围的最终响应前，检查响应本身是否包含

| 需求 | 证据 |

，并且每个行为行都有确切的测试名称。子报告或内部计划中的表格是不够的。不要将这些名称简化为模块级的项目符号或

领域 | 测试

表格。

中间状态文件是内部工作数据，绝不是交付物。保持

<TESTAGENT_DIR>

不可暂存，绝不要将其或其文件放在受版本控制的工作区内容中，也绝不要修改

.gitignore

来隐藏它们。

将完整性视为需求矩阵，而不是测试数量目标。为每个独立请求的状态、边界、错误路径或交互提供其自己的具体断言。仅当一次执行确实能证明整个请求的组合时才合并用例；不要让参数化的正向用例替代空状态、无效鉴别符或边界前/边界处/边界后的用例。

对于涉及多个生产模块或层级的宽泛请求，为每个指定模块的非平凡公共行为提供直接测试。跨模块测试可以验证组合，但不能替代所请求的模块级覆盖率。通过行为矩阵判断广度，绝不要通过达到或超过原始测试数量来判断。

在公共入口点，将宽泛工作一次性委派给

test-engineer

。研究、计划、实现和评审仍然是必需的，但它们不需要是单独的子Agent调用。

仅使用当前运行时中可用的功能。不要在别名下重试缺失的技能，也不要使用其他Agent重试被策略拒绝的操作。如果临时存储被拒绝，将研究和计划保留在上下文中，继续执行允许的测试编辑，并报告缺失的状态工件。如果执行被拒绝，继续进行允许的静态评审，并将测试报告为未运行，绝不要报告为已通过。这两种阻塞情况都不授权修改生产代码或降低需求。

对于宽泛或全面的请求，显式矩阵是底线，而不是上限。将每个请求的模块或层级视为清单标题，而不是单个行为：将其扩展为有边界的公共操作及其不同的验证路径、分支、边界、交互和状态转换。

在满足显式矩阵后，检查每个目标API的可观察等价分区和提示中未提及的不变量：恒等、空、单例和代表性内部输入；精确边界加上紧邻的值；无效分区；以及实现所隐含的排序、单调性、翻转、容量、截断或状态不变量。

为每个尚未验证的不同分区添加一个变异相关用例，仅对验证相同行为的同级用例使用参数化或表驱动用例。达到覆盖率阈值是验证，而不是广度停止条件。当剩余输入都执行相同的分支和不变量时停止，而不仅仅是在显式检查清单完成时停止；绝不要仅仅为了增加数量而添加用例。

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

当你需要执行以下操作时使用本技能：

为整个项目或特定文件生成单元测试
提高现有代码库的测试覆盖率
创建符合项目约定的测试文件
编写真正能编译并通过的测试
为新功能或未测试的代码添加测试
生成或扩展MSTest测试套件；在本入口技能确定范围和项目约定后，加载
```
writing-mstest-tests
```
作为辅助指引

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

运行或执行现有测试（使用
```
run-tests
```
技能）
在测试框架之间迁移（使用迁移技能）
回答不涉及生成测试的MSTest API/模式或现代化问题（使用
```
writing-mstest-tests
```
）
未请求代码或测试改动时，仅对失败测试做分析型诊断

How It Works

工作原理

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

本技能在研究 → 计划 → 实现流水线中协调多个专用Agent：

Pipeline Overview

流水线概览

text

┌─────────────────────────────────────────────────────────────┐
│                     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  │
              └─────────┘ └───────┘ └───────┘ └───────┘

text

┌─────────────────────────────────────────────────────────────┐
│                     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

步骤1：确定用户请求

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.

在编辑前先分类意图和范围：

生成或扩展：遵循下文的生成工作流。
修复：复现最小范围的失败，确定缺陷是在测试还是生产行为中，进行授权范围内的最小修复，然后重新运行覆盖该问题的命令。
先审计后修复：调用
```
test-engineer
```
，以便它协调内部质量专家和实现工作。

确保你理解用户的需求和范围。当用户没有对测试风格、覆盖率目标或约定提出明确要求时，从unit-test-generation.prompt.md中获取指引。该提示提供了发现约定、参数化策略、面向行为的覆盖率以及特定语言模式的最佳实践。

Step 2: Size the request before invoking anything

步骤2：在调用任何内容前评估请求规模

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:

every named behavior has a concrete assertion, including each requested boundary or error path;
the narrow test command exited successfully;
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.

根据范围匹配相应的机制。对单文件请求运行完整流水线会浪费轮次和工具调用，却不会改善测试质量。

范围	表现形式	执行方式
聚焦型	单个函数、类或文件；「仅针对X的测试」；为现有测试套件补充缺失的用例	跳过中间状态文件和子Agent分派。将需求检查清单记在脑子里（或放在最终表格中），仅阅读目标文件和一个相邻的测试文件以了解约定，编写测试，运行最窄范围的测试命令，内联评审你自己的断言。
宽泛型	项目、包或模块集；「全面的测试套件」；需要跨多个文件达到的覆盖率阈值	执行步骤3中的完整「研究 → 计划 → 实现」流水线，在 `<TESTAGENT_DIR>` 下创建中间状态文件，并遵循下文的完成契约。

如有疑问，从聚焦型开始，仅当请求确实涉及多个文件时才升级。升级只会多花一次遍历；而对聚焦型请求运行宽泛流水线则会多花好几次。

在结束聚焦型请求前，同时检查以下三个条件：

每个指定的行为都有具体的断言，包括每个请求的边界或错误路径；
最小范围的测试命令成功退出；
最终交接将这些行为映射到确切的测试名称，并引用了该成功执行的命令。

不要用通用的覆盖领域列表替代需求级别的证据。

Step 3: Invoke the Test Generator (broad scope)

步骤3：调用测试生成器（宽泛范围）

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

text

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.

test-engineer

is unavailable, do not skip the workflow. Execute the same Research → Plan → Implement sequence inline, resolve

<TESTAGENT_DIR>

as described below, create the intermediate state files there, and apply the same completion contract.

For broad scope, resolve one absolute

<TESTAGENT_DIR>

before creating intermediate state files:

Prefer a host-provided session artifact or scratch directory.
Otherwise, in a Git worktree run
```
git rev-parse --path-format=absolute --git-path testagent
```
; this returns a path in worktree-specific Git metadata that cannot be staged.
Outside Git, create a unique directory under the operating system's temporary directory.

Pass the absolute directory to every pipeline agent. The path may be inside the repository's

.git

metadata directory, but it must not be version-controlled workspace content, appear in

git status

, or be stageable.

首先调用命名为

test-engineer

的自定义Agent来处理你的测试生成请求。不要使用仅仅名为

test-engineer

的通用/通用目的子Agent：

text

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`.

测试生成器拥有流水线的所有权。在它返回后，使用其记录的质量检查、验证结果和需求矩阵，而不是作为另一个流水线重复步骤4和5。不要重新加载评审技能，也不要重新运行未改动的已通过命令。在最终交接中保留其证据中的确切测试名称。如果证据缺失，针对该特定缺口进行检查或跟进，而不要重新开始生成。报告的全能力范围拒绝也适用于调用方；不要尝试使用该能力的其他命令。

如果

test-engineer

不可用，不要跳过工作流。内联执行相同的「研究 → 计划 → 实现」序列，如下所述解析

<TESTAGENT_DIR>

，在那里创建中间状态文件，并应用相同的完成契约。

对于宽泛范围，在创建中间状态文件前先解析一个绝对的

<TESTAGENT_DIR>

：

优先使用主机提供的会话工件或临时目录。
否则，在Git工作树中运行
```
git rev-parse --path-format=absolute --git-path testagent
```
；这会返回工作树特定的Git元数据中的一个路径，该路径无法被暂存。
在Git之外，在操作系统的临时目录下创建一个唯一目录。

将该绝对目录传递给每个流水线Agent。该路径可能位于仓库的

.git

元数据目录内，但它绝不能是受版本控制的工作区内容、出现在

git status

中或可被暂存。

Step 4: Execute with bounded context

步骤4：在有界上下文中执行

For multi-file requests:

Turn every explicit user requirement into a checklist before implementation. Include requested layers, collaborators to mock, boundary cases, integrations, coverage thresholds, and report artifacts. Copy multi-condition requirements verbatim — they must each map to one test that exercises the whole combination.
Research only the requested module or project and write the checklist plus a compact target inventory to
```
<TESTAGENT_DIR>/research.md
```
.
Reuse manifests, symbol references, and deterministic pairing tools instead of reading every source and test file.
When an available
```
find-untested-sources
```
skill is useful for a substantial multi-file inventory, run it once and reuse its pairing and suggested-path output. Otherwise pair the bounded targets manually once; do not probe for an unavailable skill.
Plan each target file once, then implement phases sequentially. Map every checklist item to at least one concrete test or explain why it is blocked.
Build and test the narrow target during fix cycles. Run workspace-level validation once at the end only for broad work, when the repository contract requires that entry point, or when the changes can affect other projects.
Before reporting success, re-open the generated tests and verify every checklist item against concrete test names and assertions. Coverage alone is not evidence that a requested mock seam, boundary, state transition, or property combination was tested.
Read a language example from
```
code-testing-extensions
```
only when the repository has no representative tests and the base extension is insufficient.
For .NET, classify SDK-style vs. classic non-SDK before choosing commands or creating files. In classic projects, preserve
```
packages.config
```
, existing framework/mock versions and custom base fixtures, add every new test file to the project's explicit
```
<Compile Include>
```
items, and use the repository's MSBuild/test-runner commands. Never modernize the project or dependency stack merely to generate tests.
For MSTest, inspect the pinned package version before choosing exception assertions. MSTest 3.5.x uses
```
Assert.ThrowsException<T>
```
; do not substitute
```
[ExpectedException]
```
,
```
Assert.Throws<T>
```
, or
```
Assert.ThrowsExactly<T>
```
.

对于多文件请求：

在实现前，将每个显式用户需求转化为检查清单。包括请求的层级、要Mock的协作者、边界用例、集成、覆盖率阈值和报告工件。逐字复制多条件需求——它们每个都必须映射到一个执行整个组合的测试。
仅研究请求的模块或项目，并将检查清单加上紧凑的目标清单写入
```
<TESTAGENT_DIR>/research.md
```
。
重用清单、符号引用和确定性配对工具，而不是阅读每个源文件和测试文件。
当可用的
```
find-untested-sources
```
技能对大量多文件清单有用时，运行一次并重用其配对和建议路径输出。否则手动配对一次有界目标；不要探测不可用的技能。
为每个目标文件制定一次计划，然后按顺序实现各阶段。将每个清单项映射到至少一个具体测试，或解释其被阻塞的原因。
在修复周期中构建并测试最小范围的目标。仅在工作结束时对宽泛工作、当仓库契约要求该入口点时，或者当更改可能影响其他项目时，才运行工作区级别的验证。
在报告成功之前，重新打开生成的测试，并对照具体的测试名称和断言验证每个清单项。仅覆盖率不能证明所请求的Mock接缝、边界、状态转换或属性组合已被测试。
仅当仓库没有代表性测试且基础扩展不足时，才从
```
code-testing-extensions
```
中读取语言示例。
对于.NET，在选择命令或创建文件前，先区分SDK风格与经典非SDK风格。在经典项目中，保留
```
packages.config
```
、现有框架/Mock版本和自定义基类夹具，将每个新测试文件添加到项目的显式
```
<Compile Include>
```
项中，并使用仓库的MSBuild/测试运行器命令。绝不要仅仅为了生成测试而现代化项目或依赖栈。
对于MSTest，在选择异常断言前检查固定的包版本。MSTest 3.5.x使用
```
Assert.ThrowsException<T>
```
；不要替换为
```
[ExpectedException]
```
、
```
Assert.Throws<T>
```
或
```
Assert.ThrowsExactly<T>
```
。

Completion contract

完成契约

Every scope must satisfy points 3–5 below. Points 1 and 2 are the broad-scope artifacts: on a focused request the same reasoning happens inline and no intermediate state files are written.

Do not report completion until all of these are true:

(broad scope)
```
<TESTAGENT_DIR>/research.md
```
records the bounded target inventory, existing test conventions, and the acceptance checklist.
(broad scope)
```
<TESTAGENT_DIR>/plan.md
```
maps each checklist item to a planned test or an explicit blocker.
Generated tests compile and pass with the narrowest relevant test command, satisfying the shared report-safe naming and result-validation contract.
Every explicit user requirement is backed by a concrete test and assertion. Fix missing mock seams, boundary cases, state transitions, and property combinations even when coverage already passes. In the final summary, cite at least one generated test name for every checklist item so completion is auditable; if an item has no test to cite, keep implementing or report it as blocked. For non-behavioral requirements such as scaffolding, scope limits, commands, or coverage artifacts, cite the relevant file, command, or report instead of forcing a test-name mapping. A passing suite with fewer tests is not automatically weaker: judge completeness by whether every independently requested behavior has direct, nonredundant evidence, not by raw test volume. For broad/comprehensive scope, also verify that every observable equivalence partition and invariant discovered in the bounded target APIs has one mutation-relevant case, even when the prompt did not name it. When the request names multiple modules, verify that each module's own non-trivial public behavior has direct test evidence in addition to any end-to-end composition test.
Review the generated tests for behavior gaps and weak assertions. On a broad scope, invoke
```
test-gap-analysis
```
and
```
assertion-quality
```
when available and record the findings and fixes in
```
<TESTAGENT_DIR>/status.md
```
. On a focused scope, do the equivalent review inline — re-read each generated assertion against the source — without spawning extra passes.

The final response must provide requirement-by-requirement evidence. Use compact bullets under a Requirement coverage label for one to three focused requirements; use a

Requirement | Evidence

table for broader scopes. Behavioral evidence cites exact generated test names. Non-behavioral evidence cites the relevant project file, validation command, or coverage report. A generic list of tested areas is not a substitute.

Preserve the user's exact meaning in each evidence item; quote verbatim only when wording distinguishes a required combination. A test that merely exercises the same collaborators does not satisfy a requirement about their interaction, and per-class requirements need a citation per class.

Cite a clean run, not an attempt. The commands behind the final evidence must have finished successfully: quote the final passing test summary and, when thresholds were requested, the per-module coverage table from a run that exited 0. If the last coverage run exited non-zero, fix it and re-run before reporting; never infer threshold clearance from a failed or partial run.

Before reporting, inspect the final working-tree changes and confirm that

research.md

plan.md

status.md

, and any other intermediate state files are not among the changes intended for commit.

每种范围都必须满足以下第3-5点。第1和2点是宽泛范围的工件：对于聚焦型请求，相同的推理在内联中进行，不会写入中间状态文件。

在所有以下条件都满足之前，不要报告完成：

(宽泛范围)
```
<TESTAGENT_DIR>/research.md
```
记录了有界目标清单、现有测试约定和验收检查清单。
(宽泛范围)
```
<TESTAGENT_DIR>/plan.md
```
将每个清单项映射到计划的测试或显式阻塞原因。
生成的测试可以编译并通过最窄范围的相关测试命令，满足共享的报告安全命名和结果验证契约。
每个显式用户需求都有具体的测试和断言支持。即使覆盖率已经通过，也要修复缺失的Mock接缝、边界用例、状态转换和属性组合。在最终总结中，为每个清单项引用至少一个生成的测试名称，以便完成情况可审计；如果某个项没有可引用的测试，继续实现或将其报告为阻塞。对于脚手架、范围限制、命令或覆盖率工件等非行为需求，引用相关的文件、命令或报告，而不是强制映射测试名称。测试数量较少的通过套件并不自动更弱：通过每个独立请求的行为是否有直接的、非冗余的证据来判断完整性，而不是通过原始测试数量。对于宽泛/全面范围，还要验证在有界目标API中发现的每个可观察等价分区和不变量都有一个变异相关用例，即使提示中没有提及。当请求涉及多个模块时，验证除了任何端到端组合测试之外，每个模块自身的非平凡公共行为都有直接的测试证据。
评审生成的测试是否存在行为缺口和弱断言。对于宽泛范围，在可用时调用
```
test-gap-analysis
```
和
```
assertion-quality
```
，并将发现和修复记录在
```
<TESTAGENT_DIR>/status.md
```
中。对于聚焦型范围，内联执行等效的评审——对照源代码重新读取每个生成的断言——而不需要额外的遍历。

最终响应必须提供逐需求的证据。对于1到3个聚焦型需求，在需求覆盖标签下使用紧凑的项目符号；对于更宽泛的范围，使用

需求 | 证据

表格。行为证据引用确切的生成测试名称。非行为证据引用相关的项目文件、验证命令或覆盖率报告。通用的测试领域列表不能替代。

在每个证据项中保留用户的确切含义；仅当措辞区分了所需的组合时才逐字引用。仅仅执行了相同协作者的测试不能满足关于其交互的需求，每个类的需求需要每个类都有引用。

引用一次干净的运行，而不是一次尝试。 最终证据背后的命令必须成功完成：引用最终的通过测试摘要，以及在要求阈值时，引用退出码为0的运行的每模块覆盖率表。如果最后一次覆盖率运行以非零值退出，在报告前修复并重新运行；绝不要从失败或部分运行中推断阈值达标。

在报告前，检查最终的工作树更改，确认

research.md

、

plan.md

、

status.md

和任何其他中间状态文件不在打算提交的更改之中。

State Management

状态管理

Broad-scope runs store intermediate state files in a non-stageable

<TESTAGENT_DIR>

backed by host scratch storage, Git metadata, or OS temp. A focused request does not create these files:

File	Purpose
`<TESTAGENT_DIR>/research.md`	Codebase analysis results
`<TESTAGENT_DIR>/plan.md`	Phased implementation plan
`<TESTAGENT_DIR>/status.md`	Final quality review and fixes

宽泛范围运行将中间状态文件存储在不可暂存的

<TESTAGENT_DIR>

中，该目录由主机临时存储、Git元数据或操作系统临时目录支持。聚焦型请求不会创建这些文件：

文件	用途
`<TESTAGENT_DIR>/research.md`	代码库分析结果
`<TESTAGENT_DIR>/plan.md`	分阶段实现计划
`<TESTAGENT_DIR>/status.md`	最终质量评审与修复

Agent Reference

Agent参考

Agent	Purpose
`test-engineer`	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

Agent	用途
`test-engineer`	协调流水线
`code-testing-researcher`	分析代码库
`code-testing-planner`	创建测试计划
`code-testing-implementer`	编写测试文件
`code-testing-builder`	编译代码
`code-testing-tester`	运行测试
`code-testing-fixer`	修复错误
`code-testing-linter`	格式化代码

Requirements

要求

Project must have a build/test system configured
Testing framework should be installed (or installable)
VS Code with GitHub Copilot extension

Classic non-SDK .NET projects are supported when their existing build/test toolchain is available. When it is not available on the current machine, the agent can still add and register version-compatible tests, but must report execution as blocked rather than substituting

dotnet test

项目必须配置了构建/测试系统
测试框架应已安装（或可安装）
安装了GitHub Copilot扩展的VS Code

当经典非SDK .NET项目的现有构建/测试工具链可用时，支持此类项目。当当前机器上没有该工具链时，Agent仍然可以添加并注册版本兼容的测试，但必须报告执行被阻塞，而不是替代为

dotnet test

。

Troubleshooting

故障排除

Tests don't compile

测试无法编译

The

code-testing-fixer

agent will attempt to resolve compilation errors. Check

<TESTAGENT_DIR>/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).

code-testing-fixer

Agent将尝试解决编译错误。查看

<TESTAGENT_DIR>/plan.md

了解预期的测试结构。调用

code-testing-extensions

技能并阅读特定语言的扩展文件以获取错误代码参考（例如.NET的

dotnet.md

）。

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

生成的测试中的大多数失败是由断言中的预期值错误引起的，而不是生产代码错误：

读取实际的测试输出
阅读生产代码以理解正确行为
修复断言，而不是生产代码
绝不要仅仅为了让测试通过而将测试标记为
```
[Ignore]
```
或
```
[Skip]
```

Wrong testing framework detected

检测到错误的测试框架

Specify your preferred framework in the initial request: "Generate Jest tests for..."

在初始请求中指定你偏好的框架：「为...生成Jest测试」

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.

依赖外部服务、网络端点、特定端口或精确时序的测试在CI环境中会失败。请专注于使用Mock依赖的单元测试。

Broader validation fails

更宽泛的验证失败

During implementation, build and test the narrow target. Run a solution or workspace-level command only for broad work, when the repository contract uses that entry point, or when the targeted change can affect other projects. Do not turn a focused test request into an unconditional full non-incremental build.

在实现期间，构建并测试最小范围的目标。仅对宽泛工作、当仓库契约使用该入口点时，或者当目标更改可能影响其他项目时，才运行解决方案或工作区级别的命令。不要将聚焦型测试请求变成无条件的完整非增量构建。