Goal
Use the smallest test type that can provide meaningful confidence to prove the behavior that callers truly depend on. Test code should focus on rules, transformations, boundaries, and errors, and should not verify test setup code or the language itself.
Readability check before writing
Every time content is added or updated, the full text to be written must first be polished and checked.humanizer-zh When the skill is available, it must be called, and its SKILL.mdmust be read in full and applied. If the current task has already read it and the file has not changed, it may be reused; when it is unavailable, complete the check according to the plain-language rules below and continue writing.
The scope includes all test names, comments, JSDoc, review records, test descriptions, and other explanatory text written this time. First determine the behavior to be verified, then polish the draft according to the above rules, check the meaning, and write it. It is not enough to polish only the final reply or part of the file.
Preserve the behavior, conditions, negation, expected results, and degree of certainty verified by the test. Code, identifiers, commands, paths, URLs, link targets, structured data, test inputs, and assertion values remain unchanged. Test names may be polished, but they must still accurately state the scenario and expected behavior. If the text is modified again after writing, the modified part must also undergo the same treatment.
humanizer-zh When it is unavailable, use common words and short sentences to explain under what conditions the test verifies what behavior and what the expected result is; explain necessary terminology in plain language, remove empty words and repetition, and do not add unverified information. Read it through from the perspective of a reader who has just taken over the test, and confirm that the test purpose and what a failure means can be understood. Continue to complete the writing, and briefly state in the report that the plain-language rules were used, without claiming that the skill was called.
Execution flow
[收到测试任务]
|
v
[定位真实风险与可观察行为]
|
| 完成：能说明删除哪条规则会使测试失败
v
[按真实依赖边界选择测试类型]
|
| 完成：测试类型与实际触达边界一致
v
[按读取规则加载 reference]
|
v
[删除或改写无意义测试]
|
| 完成：每个断言都会在目标行为回归时失败
v
[检查全部待写入文字的可读性，再写入]
|
| 完成：文字易读，测试行为、输入和断言值保持准确
v
[运行最小相关测试、文件级 lint 和类型检查]
|
| 完成：所有命令无错误、无警告，且未放宽断言
v
[报告修改、保护行为与验证结果]
Reading rules
- When selecting or adjusting test types, read references/test-types.md。
- When adding, modifying, or reviewing unit test assertions, naming, test data, and comments, read references/assertions-and-comments.md。
- When tests use mocks, stubs, spies, or involve real dependency boundaries, read references/mocking.md。
- When adding, modifying, or reviewing any test, you must read references/anti-patterns.md, and use the negative examples in it to clean up meaningless test logic.
Completion criteria
- Tests retain only assertions about real behavior, boundaries, errors, or external contracts.
- The expected value is independently defined by the rule, not copied as-is from the setup object.
- Mocks only isolate collaborators unrelated to the current risk, and do not replace the behavior being verified.
- Unit test blocks and assertion comments comply with project conventions, and comments state the purpose, summary, and expectation.
- Complete the minimum relevant verification; expand the scope only when shared behavior is affected.
Response requirements
Report only the selected test type and the reason, the meaningless logic deleted or rewritten, the behavior currently protected, and the verification commands actually executed and their results.