Back to Details

test

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Run Tests and Fix Failures

运行测试并修复失败问题

Detect test framework, run tests, diagnose and fix failures automatically.
自动检测测试框架、运行测试、诊断并修复测试失败问题。

Instructions

操作说明

Step 1: Detect Test Framework

步骤1：检测测试框架

Check for test configuration files in this order:
FileFrameworkRun Command
vitest.config.*
or 
vite.config.*
with test		Vitest
npx vitest run
jest.config.*
or 
package.json
jest key		Jest
npx jest
phpunit.xml
PHPUnit
./vendor/bin/phpunit
pest.php
or Pest in composer.json		Pest
./vendor/bin/pest
pytest.ini
/ 
pyproject.toml
[tool.pytest]		pytest
pytest
go.mod
with 
_test.go
files		Go
go test ./...
Cargo.toml
Rust
cargo test
Gemfile
with rspec		RSpec
bundle exec rspec
Also check 
package.json
scripts for 
test
, 
test:run
, 
test:unit
, 
test:integration
.
If CLAUDE.md specifies test commands, use those instead.
按以下顺序检查测试配置文件：
文件测试框架运行命令
vitest.config.*
或包含test配置的
vite.config.*
Vitest
npx vitest run
jest.config.*
或
package.json
中的jest配置项		Jest
npx jest
phpunit.xml
PHPUnit
./vendor/bin/phpunit
pest.php
或composer.json中包含Pest		Pest
./vendor/bin/pest
pytest.ini
/ 
pyproject.toml
中的[tool.pytest]配置		pytest
pytest
包含
_test.go
文件的
go.mod
Go
go test ./...
Cargo.toml
Rust
cargo test
包含rspec的
Gemfile
RSpec
bundle exec rspec
同时检查
package.json
的scripts中是否有
test
、
test:run
、
test:unit
、
test:integration
命令。
如果CLAUDE.md中指定了测试命令，则优先使用该命令。

Step 2: Run Tests

步骤2：运行测试

Run the detected test command with 
run_in_background=true
. Use verbose output flags where available.
使用
run_in_background=true
运行检测到的测试命令。在支持的情况下使用详细输出标志。

Step 3: Analyze Results

步骤3：分析结果

If all tests pass, report the summary and stop.
If tests fail, for each failure:
  1. Read the failing test to understand what it expects
  2. Read the source code being tested
  3. Classify the failure:
    • Test is wrong — test expectations don't match intended behavior (update test)
    • Source is wrong — code has a bug (fix source)
    • Both need updating — behavior changed intentionally (update both)
    • Environment issue — missing dependency, stale cache, wrong config (fix setup)
如果所有测试通过，则报告总结并停止流程。
如果测试失败，针对每个失败项：
  1. 阅读失败测试用例以了解其预期结果
  2. 阅读被测试的源代码
  3. 对失败类型进行分类：
    • 测试用例错误——测试预期与预期行为不符（更新测试用例）
    • 源代码错误——代码存在bug（修复源代码）
    • 两者均需更新——行为已被有意修改（同时更新测试用例和源代码）
    • 环境问题——缺少依赖、缓存过期或配置错误（修复环境配置）

Step 4: Fix and Re-run

步骤4：修复并重新运行

For each failure:
  1. Make the minimal fix
  2. Re-run the specific failing test to verify
  3. Move to the next failure
After all individual fixes, run the full suite once more to catch regressions.
针对每个失败项：
  1. 进行最小化修复
  2. 重新运行特定的失败测试用例以验证修复效果
  3. 处理下一个失败项
在完成所有单独修复后，再次运行完整测试套件以检查是否存在回归问题。

Step 5: Report

步骤5：生成报告

undefined
undefined

Test Results

测试结果

Framework: [detected framework] Command: [command used] Result: X passed, Y fixed, Z remaining
测试框架： [检测到的框架] 运行命令： [使用的命令] 结果： X项通过，Y项已修复，Z项仍失败

Fixed

已修复项

  • [test name]: [what was wrong and what was fixed]
  • [测试用例名称]：[问题描述及修复内容]

Still Failing (if any)

仍失败项（如有）

  • [test name]: [diagnosis and why it couldn't be auto-fixed]
undefined
  • [测试用例名称]：[诊断结果及无法自动修复的原因]
undefined

Rules

规则

  • Never delete or skip a failing test without explicit user approval
  • Prefer fixing source over fixing tests (tests define expected behavior)
  • If a fix requires changing more than ~20 lines, show the proposed change and ask before applying
  • If the same root cause produces multiple failures, fix the root cause once
  • 未经用户明确批准，不得删除或跳过失败的测试用例
  • 优先修复源代码而非测试用例（测试用例定义了预期行为）
  • 如果修复需要修改约20行以上代码，需先展示拟议的修改内容并征得用户同意后再应用
  • 如果多个失败项由同一根本原因导致，只需修复该根本原因一次