Workflow
1. Read the real contract
Inspect the target code and its:
- Type definitions, public documentation, callers, and error-handling paths.
- Existing tests, fixtures, test configuration, dependency manifests, and project test commands.
- Inputs and outputs, side effects, state changes, concurrency semantics, and system boundaries.
- Applicable repository rules, Git status, and the scope allowed for modification in this round.
Distinguish between "the code's current behavior" and "the product's expected behavior." When the two conflict or the contract is unclear and would change assertions, first list the evidence and assumptions to be confirmed; do not use tests to cement guesses.
2. Choose the test level
- Prefer fast, deterministic unit tests for pure logic.
- Isolate time, randomness, the file system, the network, or third-party services at system boundaries, and avoid mocking the internal implementation of the module under test.
- Use integration tests when real component collaboration needs to be verified; temporary directories, test databases, or controlled services may be used, and resource isolation and cleanup must be ensured.
- When fixing a defect, first write the smallest regression case that reproduces the real problem, then verify the fix.
Only cover normal, boundary, and failure scenarios that actually exist in the contract or reachable paths. Null values, type errors, timeouts, and database exceptions are not fixed requirements for every function.
3. Design cases
Each case should state:
- The corresponding contract, defect, or branch.
- The inputs and environment setup.
- Observable results, not internal implementation details.
- Necessary cleanup and isolation across cases.
Prefer parameterizing repeated scenarios, and follow the repository's existing test naming, directory, fixture, and assertion style. Do not force Chinese function names just because the project targets Chinese users.
4. Implement the minimal tests
- Only modify the target test files and fixtures that are truly necessary.
- Do not arbitrarily modify production code just to make tests pass; if a product defect is found, report it separately or fix it as requested by the user.
- Do not copy unverified example expected values, and do not write implementation details into a permanent contract.
- On Windows and Linux, use path APIs, the system temporary directory, and explicit encoding; do not hardcode separators,
/tmp, newlines, case, time zones, or locale behavior.
5. Run and re-verify
- First run the new or target tests and confirm that the failure messages match expectations.
- First check whether project scripts will download dependencies, access external services, or change shared state, then run the relevant tests according to the change risk; when necessary, run the full test suite, type checks, or coverage commands, and obtain authorization first for potential external side effects.
- Check the Git diff to confirm there are no snapshots, caches, coverage artifacts, or unrelated files.
- Record pre-existing baseline failures separately from new failures introduced in this round.
When there is no actual run, you can only state "generated, not verified"; you cannot claim the tests pass.
Security and authorization boundaries
- Do not install or upgrade testing frameworks, modify lockfiles, global test configurations, CI, or production code without explicit authorization.
- Do not access real networks, production databases, cloud services, or environments containing real credentials without explicit authorization.
- Test data must not contain real personal information, tokens, cookies, passwords, or customer data.
- Tests must be repeatable, must not depend on execution order, and must clean up temporary resources they create.
- When the target file already has user modifications, first check whether they overlap to avoid overwriting them.
Output
## 测试补充结果
- 目标与契约依据：
- 测试层级与框架：
- 新增或修改文件：
## 用例
| 场景 | 契约依据 | 预期结果 |
|------|----------|----------|
## 验证
- 实际命令与退出状态：
- 相关测试 / 完整测试：
- 基线已有失败：
- 未验证假设与限制：