fix-testing

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Fix a Red Test

修复失败测试

$ARGUMENTS

names what is red — a test file, a class, pasted failure output, or nothing at all. When it is nothing, run the suite and let the failures name themselves.

$ARGUMENTS

指明当前失败的内容——可以是测试文件、类、粘贴的失败输出，或者什么都不填。如果什么都不填，就运行测试套件，让失败信息自行指出问题。

1. Reproduce

1. 复现问题

Name the project from its root marker, then pick the row by the language of the red test. A Laravel project that is red on both sides takes both Laravel rows.

Project	Red test	Run one file	Also run
Laravel — `artisan` in the root	Pest (PHP) — call the `pest-testing` skill for how each test is written	`php artisan test --compact tests/Feature/FooTest.php`	Larastan / PHPStan, Pint
Laravel — `artisan` in the root	Vitest (Vue / TypeScript / JavaScript)	`npx vitest run resources/…/foo.test.ts`	`npm run types:check`
Flutter — `pubspec.yaml` in the root	Dart	`flutter test test/foo_test.dart`	`flutter analyze`

Run the red test on its own and read the failure. One test file at a time, start to finish — tests run together share state, a database, a module cache, a filesystem, and a neighbour's leftovers will send you chasing the wrong failure.

Done when you can name the assertion that failed and the line of app code it reached.

根据项目的根目录标志识别项目，然后按照失败测试所使用的语言选择对应行。如果一个 Laravel 项目的两种测试都失败，则需要执行两个 Laravel 行。

项目	失败测试	运行单个文件	同时运行
Laravel——根目录中有 `artisan`	Pest（PHP）——调用 `pest-testing` skill，了解每个测试的编写方式	`php artisan test --compact tests/Feature/FooTest.php`	Larastan / PHPStan、Pint
Laravel——根目录中有 `artisan`	Vitest（Vue / TypeScript / JavaScript）	`npx vitest run resources/…/foo.test.ts`	`npm run types:check`
Flutter——根目录中有 `pubspec.yaml`	Dart	`flutter test test/foo_test.dart`	`flutter analyze`

单独运行失败测试并阅读失败信息。每次只运行一个测试文件，并从头执行到尾——一起运行的测试会共享状态、数据库、模块缓存和文件系统，邻近测试遗留的内容还可能让你追查错误的失败原因。

完成标准：能够指出失败的断言，以及测试执行到的那一行应用代码。

2. Reach a verdict

2. 得出结论

A test goes red for one of two reasons, and git tells them apart. Read the recent change —

git status

and

git diff

for uncommitted work,

git log -p -n 5

and

git show <commit>

for what landed recently — then compare the code the test reaches against what changed there.

Verdict	The evidence	What you fix
Stale test	The change deliberately moved what the test asserts on — renamed method, new field, different return shape	The test, so it asserts on the new shape
Regression	The change altered behaviour it never meant to, and the test caught it	The code — call the `fix` skill. Editing the test here buries a live bug

State the verdict and quote the diff that proves it before you edit anything. When the evidence supports both readings, or neither, ask the user which it is.

Done when every red test carries a named verdict backed by a diff.

测试失败只有两种原因，而 git 可以帮助区分它们。查看最近的变更——对于未提交的改动，使用

git status

和

git diff

；对于最近合入的内容，使用

git log -p -n 5

和

git show <commit>

——然后比较测试执行到的代码与该代码中发生的变更。

结论	证据	修复对象
过期测试	变更有意调整了测试断言的对象——方法被重命名、新增字段、返回结构发生变化	修复测试，使其断言新的结构
回归问题	变更无意中改变了原有行为，而测试捕获到了该问题	修复代码——调用 `fix` skill。此时修改测试会掩盖仍然存在的 bug

在编辑任何内容之前，先说明结论，并引用能够证明结论的 diff。如果证据支持两种解释，或者两种解释都不成立，就询问用户具体情况。

完成标准：每个失败测试都有明确的结论，并有 diff 作为依据。

3. Carry out the fix

3. 执行修复

Take the verdicts one at a time, re-running that test file and its

Also run

checks after each. Run the whole suite once at the end.

Done when the suite is green and every test still asserts as much as it did before.

每次处理一个结论，并在每次修复后重新运行对应的测试文件和“同时运行”检查。最后运行一次完整的测试套件。

完成标准：测试套件全部通过，并且每个测试的断言覆盖范围都不弱于修复前。

House rules

基本规则

The back office runs Filament v5; look up its testing helpers before you change a back-office test
Look a package up with context7 before you reach for a method you have not already seen in this codebase

后台系统使用 Filament v5；修改后台测试前，先查找其 testing helpers
使用尚未在本代码库中出现过的方法前，先通过 context7 查询相关依赖包的资料