codeprobe-testing

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Standalone Mode

独立模式

If invoked directly (not via the orchestrator), you must first:

Read
```
../codeprobe/shared-preamble.md
```
for the output contract, execution modes, and constraints.
Load applicable reference files from
```
../codeprobe/references/
```
based on the project's tech stack.
Default to
```
full
```
mode unless the user specifies otherwise.

如果直接调用（不通过编排器），你必须首先：

读取
```
../codeprobe/shared-preamble.md
```
以了解输出约定、执行模式和约束条件。
根据项目技术栈加载
```
../codeprobe/references/
```
中的适用参考文件。
除非用户另有指定，默认使用
```
full
```
模式。

Test Quality & Coverage Auditor

测试质量与覆盖率审核器

Domain Scope

领域范围

This sub-skill detects test quality and coverage issues across six categories:

Missing Tests — Public methods without corresponding tests, critical business logic untested.
Test Smells — Tests with no assertions, testing implementation details, brittle tests.
Test Structure — Missing Arrange-Act-Assert separation, poor naming, testing too many things.
Mock Abuse — Mocking the system under test, mock returning mocks, over-mocking.
Coverage Gaps — No tests for error paths, authorization logic, edge cases.
Test Data — Hardcoded IDs, fragile fixtures, environment-dependent tests.

该子技能检测六大类测试质量和覆盖率问题：

缺失测试 —— 无对应测试的公共方法、未测试的关键业务逻辑。
测试异味 —— 无断言的测试、测试实现细节、脆弱的测试。
测试结构 —— 缺少Arrange-Act-Assert分离、命名不佳、测试内容过多。
滥用Mock —— 对被测系统进行Mock、Mock返回Mock、过度Mock。
覆盖率缺口 —— 错误路径、授权逻辑、边缘场景无测试覆盖。
测试数据 —— 硬编码ID、脆弱的测试夹具、依赖环境的测试。

What It Does NOT Flag

不标记的内容

Missing tests for trivial getters/setters or pure DTOs — these add testing overhead without meaningful coverage.
Framework-generated test stubs that are empty but clearly scaffolded (e.g., Laravel's
```
ExampleTest.php
```
, Create React App's
```
App.test.js
```
) — these are starting points, not abandoned tests.
Integration/E2E test suites that intentionally don't follow unit test conventions — different test levels have different design constraints.
Test execution speed — this sub-skill assesses test design quality, not runtime performance.
Tests in
vendor/
,
node_modules/
, or other dependency directories.

琐碎的getter/setter或纯DTO的缺失测试 —— 这些测试只会增加测试开销，无法提供有意义的覆盖率。
框架生成的空测试桩（如Laravel的
```
ExampleTest.php
```
、Create React App的
```
App.test.js
```
）—— 这些是起始模板，并非废弃测试。
有意不遵循单元测试规范的集成/E2E测试套件 —— 不同层级的测试有不同的设计约束。
测试执行速度 —— 该子技能评估测试设计质量，而非运行时性能。
vendor/
、
node_modules/
或其他依赖目录中的测试。

Detection Instructions

检测说明

Severity Ceiling

严重程度上限

No finding from this sub-skill should ever be classified as Critical. Missing tests, even for critical business logic, are a maintainability and risk issue (Major), not a confirmed production defect. The highest severity this sub-skill may assign is Major. Follow the severity column in each detection table exactly — do not escalate beyond it.

该子技能的任何检测结果都不应被归类为Critical（严重）。即使关键业务逻辑缺失测试，也属于可维护性和风险问题（Major，主要），而非已确认的生产缺陷。该子技能可分配的最高严重程度为Major。严格遵循每个检测表格中的严重程度列——不得超出此级别。

Missing Tests

缺失测试

ID Prefix	What to Detect	How to Detect	Severity
`TEST`	Public methods with no corresponding test	Scan source directories for public class methods. For each, check if a corresponding test file/method exists. Use test file naming conventions: `test_` , `_test.` , `.test.` , `Test[A-Z]` , `spec_` , `_spec.` , `.spec.` (matching `file_stats.py` patterns).	Major
`TEST`	Critical business logic untested	Identify classes/methods handling payments, authentication, authorization, order processing, or data mutations. Check whether these have dedicated test coverage.	Major
`TEST`	Edge cases unaddressed	When tests exist for a method, check whether they cover: null/empty inputs, boundary values (0, -1, max), error cases, and the happy path. Flag methods with only happy-path tests.	Minor

ID前缀	检测内容	检测方式	严重程度
`TEST`	无对应测试的公共方法	扫描源码目录中的公共类方法，为每个方法检查是否存在对应的测试文件/方法。使用测试文件命名约定： `test_` 、 `_test.` 、 `.test.` 、 `Test[A-Z]` 、 `spec_` 、 `_spec.` 、 `.spec.` （匹配 `file_stats.py` 的模式）。	Major
`TEST`	未测试的关键业务逻辑	识别处理支付、认证、授权、订单处理或数据变更的类/方法，检查这些类/方法是否有专门的测试覆盖。	Major
`TEST`	未覆盖的边缘场景	当方法已有测试时，检查是否覆盖了：空/Null输入、边界值（0、-1、最大值）、错误场景以及正常路径。标记仅覆盖正常路径的方法。	Minor

Test Smells

测试异味

ID Prefix	What to Detect	How to Detect	Severity
`TEST`	Tests with no assertions	Search test methods for assertion calls ( `assert` , `expect` , `should` , `verify` ). Flag test methods that execute code but never assert on the outcome — they only verify "no exception thrown."	Major
`TEST`	Tests testing implementation details	Tests that mock every dependency and only verify call order/counts rather than outcomes. Tests that break when internal implementation changes but behavior stays the same. Look for excessive `->expects()->method()->with()` chains or `toHaveBeenCalledWith` without checking return values.	Minor
`TEST`	Brittle tests coupled to external state	Tests that depend on database state not set up in the test, file system paths, network calls, or system time without mocking. Look for raw SQL in tests, `file_exists()` checks, HTTP calls without mocking.	Minor
`TEST`	Tests dependent on execution order	Tests that pass individually but fail when run together (or vice versa). Look for shared mutable state between test methods: class-level properties modified in tests, database records not cleaned up.	Major

ID前缀	检测内容	检测方式	严重程度
`TEST`	无断言的测试	在测试方法中搜索断言调用（ `assert` 、 `expect` 、 `should` 、 `verify` ）。标记仅执行代码但从不断言结果的测试方法——这些测试仅验证“未抛出异常”。	Major
`TEST`	测试实现细节的测试	对所有依赖进行Mock，仅验证调用顺序/次数而非结果的测试；当内部实现变更但行为不变时会失败的测试。查找过多的 `->expects()->method()->with()` 链式调用或未检查返回值的 `toHaveBeenCalledWith` 。	Minor
`TEST`	依赖外部状态的脆弱测试	依赖测试中未设置的数据库状态、文件系统路径、网络调用或系统时间且未进行Mock的测试。查找测试中的原生SQL、 `file_exists()` 检查、未Mock的HTTP调用。	Minor
`TEST`	依赖执行顺序的测试	单独运行通过但一起运行失败（或反之）的测试。查找测试方法间的共享可变状态：测试中修改的类级属性、未清理的数据库记录。	Major

Test Structure

测试结构

ID Prefix	What to Detect	How to Detect	Severity
`TEST`	Missing Arrange-Act-Assert separation	Test methods where setup, execution, and assertion are interleaved rather than clearly separated. Multiple act+assert cycles in one test.	Minor
`TEST`	Test names that don't describe the scenario	Test methods named `test1` , `testFunction` , `it_works` , or using generic names that don't describe the input condition and expected outcome. Good: `test_empty_cart_returns_zero_total` . Bad: `testCalculate` .	Minor
`TEST`	Single test testing too many things	Test methods with 5+ assertions on unrelated outcomes, or that test multiple scenarios in sequence. Should be split into focused tests.	Minor

ID前缀	检测内容	检测方式	严重程度
`TEST`	缺少Arrange-Act-Assert分离	测试方法中设置、执行和断言交织在一起，而非清晰分离；单个测试中包含多个执行+断言周期。	Minor
`TEST`	未描述场景的测试名称	测试方法命名为 `test1` 、 `testFunction` 、 `it_works` 或使用未描述输入条件和预期结果的通用名称。良好示例： `test_empty_cart_returns_zero_total` 。不良示例： `testCalculate` 。	Minor
`TEST`	单个测试内容过多	测试方法包含5个以上无关结果的断言，或按顺序测试多个场景。应拆分为聚焦的测试。	Minor

Mock Abuse

滥用Mock

ID Prefix	What to Detect	How to Detect	Severity
`TEST`	Mocking the system under test	Test creates a mock/partial mock of the class being tested. The test is testing the mock, not the actual code. Look for `$this->createPartialMock(ClassName::class)` or `jest.spyOn(sut, 'method')` where sut is the class being tested.	Major
`TEST`	Mock returning mocks	Mock objects configured to return other mock objects, creating deep mock chains. `$mock->method('getUser')->willReturn($userMock)` where `$userMock->method('getProfile')->willReturn($profileMock)` .	Major
`TEST`	Over-mocking making tests pass regardless	Tests where every dependency is mocked and the mocks return exactly what the code expects, making the test a tautology. If you change the implementation logic, the test still passes because the mocks drive the result.	Minor

ID前缀	检测内容	检测方式	严重程度
`TEST`	对被测系统进行Mock	测试创建被测类的Mock/部分Mock，实际测试的是Mock而非真实代码。查找 `$this->createPartialMock(ClassName::class)` 或 `jest.spyOn(sut, 'method')` （其中sut是被测类）。	Major
`TEST`	Mock返回Mock	Mock对象被配置为返回其他Mock对象，形成深层Mock链。例如 `$mock->method('getUser')->willReturn($userMock)` ，其中 `$userMock->method('getProfile')->willReturn($profileMock)` 。	Major
`TEST`	过度Mock导致测试无论如何都通过	所有依赖都被Mock，且Mock返回代码预期的结果，使测试成为同义反复。即使修改实现逻辑，测试仍会通过，因为结果由Mock驱动。	Minor

Coverage Gaps

覆盖率缺口

ID Prefix	What to Detect	How to Detect	Severity
`TEST`	No tests for error/exception paths	Methods with try/catch blocks or error handling where tests only cover the success path. No test triggers the catch/error branch.	Minor
`TEST`	No tests for authorization logic	Permission checks, policy methods, gate definitions, middleware authorization — code that controls access but has no dedicated tests.	Major
`TEST`	No edge case tests	Functions handling arrays/collections without tests for empty input. Numeric functions without tests for zero, negative, or boundary values. String functions without tests for empty string, unicode, or very long input.	Minor

ID前缀	检测内容	检测方式	严重程度
`TEST`	错误/异常路径无测试	包含try/catch块或错误处理的方法，但测试仅覆盖成功路径，无测试触发catch/错误分支。	Minor
`TEST`	授权逻辑无测试	权限检查、策略方法、网关定义、中间件授权——控制访问但无专门测试的代码。	Major
`TEST`	边缘场景无测试	处理数组/集合的函数无空输入测试；数值函数无零、负数或边界值测试；字符串函数无空字符串、unicode或超长输入测试。	Minor

Test Data

测试数据

ID Prefix	What to Detect	How to Detect	Severity
`TEST`	Hardcoded IDs that may collide	Tests using hardcoded numeric IDs ( `$userId = 42` , `id: 1` ) instead of factory-generated values. These collide in parallel test runs or with seeded data.	Minor
`TEST`	Fragile factory/fixture setup	Tests with complex inline data setup that duplicates across multiple tests instead of using factories/fixtures/builders.	Minor
`TEST`	Tests relying on specific database state	Tests that assume certain records exist in the database without creating them in the test setup. Depends on seeders or previous test execution.	Minor

ID前缀	检测内容	检测方式	严重程度
`TEST`	可能冲突的硬编码ID	测试使用硬编码数值ID（如 `$userId = 42` 、 `id: 1` ）而非工厂生成的值。这些ID在并行测试运行或与种子数据共存时会发生冲突。	Minor
`TEST`	脆弱的工厂/夹具设置	测试使用复杂的内联数据设置，且在多个测试中重复，未使用工厂/夹具/构建器。	Minor
`TEST`	依赖特定数据库状态的测试	测试假设数据库中存在某些记录，但未在测试设置中创建这些记录，依赖种子数据或之前的测试执行结果。	Minor

ID Prefix & Fix Prompt Examples

ID前缀与修复提示示例

All findings use the

TEST-

prefix, numbered sequentially:

TEST-001

TEST-002

, etc.

所有检测结果使用

TEST-

前缀，按顺序编号：

TEST-001

、

TEST-002

等。

Fix Prompt Examples

修复提示示例

"Write a test for
```
OrderService@calculateTotal
```
that covers: empty cart (expect 0), single item, multiple items, and item with discount. Use
```
OrderFactory
```
for test data. Place in
```
tests/Unit/Services/OrderServiceTest.php
```
."

"The test

test_user_can_login

tests/Feature/AuthTest.php:25

has no assertions — it only calls the login endpoint. Add

assertStatus(200)

assertAuthenticated()

, and

assertJsonStructure(['token'])

assertions."

"In
```
tests/Unit/PaymentServiceTest.php:40
```
, the mock chain is mocking too deeply. Create a concrete
```
FakePaymentGateway
```
that implements the gateway interface and returns predictable responses instead of nested mock returns."
"Replace the hardcoded user ID
```
42
```
in
```
tests/Feature/OrderTest.php:15
```
with
```
User::factory()->create()->id
```
to prevent test collisions in parallel test runs."

"为
```
OrderService@calculateTotal
```
编写测试，覆盖：空购物车（预期返回0）、单个商品、多个商品以及带折扣的商品。使用
```
OrderFactory
```
生成测试数据，将测试文件放在
```
tests/Unit/Services/OrderServiceTest.php
```
中。"

"位于

tests/Feature/AuthTest.php:25

的测试

test_user_can_login

无断言——仅调用了登录端点。添加

assertStatus(200)

、

assertAuthenticated()

和

assertJsonStructure(['token'])

断言。"

"在
```
tests/Unit/PaymentServiceTest.php:40
```
中，Mock链嵌套过深。创建一个实现网关接口的具体
```
FakePaymentGateway
```
，返回可预测的响应，而非嵌套的Mock返回。"
"将
```
tests/Feature/OrderTest.php:15
```
中的硬编码用户ID
```
42
```
替换为
```
User::factory()->create()->id
```
，以避免并行测试运行时的测试冲突。"