自动生成的测试常常测实现细节。下面这些 Prompt 命中基于行为的测试。
适合哪些场景
准备重构前补测试的工程师、PR 必须达覆盖率门槛的贡献者、上线前需要安全网的独立开发者、刚接手无测试代码的人。
什么时候不建议这样写 Prompt
不打算保留的代码别写测试，先写规格；一次性脚本和琐碎 getter/setter 也不值得，测试成本远超漏 bug 代价。
Prompt 结构公式
测试生成 Prompt 一定要带这六个要素：
- 被测对象：函数 / 模块 / endpoint，附签名与类型。
- 测试分类：unit / integration / e2e / property——不要笼统”写测试”。
- 行为契约：代码”必须做什么”，不是”当前怎么写的”，否则得到 change-detector 测试。
- 覆盖范围：happy path + N 个边界 + 1 个非法输入——明确数量强迫完整。
- 框架与风格：vitest / pytest / go test，附 mock vs 真实预期。
- 输出形态：可运行代码，除非要求否则不夹散文。
这套 Prompt 适合用在哪
- 新特性测试
- 回归测试
- edge case 覆盖
- 重构前安全网
- 收紧 flaky 测试套件
13 个可直接复制的 Prompt 模板
1. 基于行为的单测
为 {function} 按可观察行为写单测，不测内部状态。覆盖：happy path、3 个 edge case、1 个非法输入。用 {框架}。2. 从 bug 报告写回归测试
Bug：{描述}。复现：{步骤}。请写 1 个最小失败测试，未修前必失败，修后必通过。3. 性质测试想法
为 {function} 识别 3 个应永远成立的性质（如"无论输入顺序，输出有序"）。写性质测试桩。4. 边界输入测试
为 {带类型的 function} 生成边界测试：空、单、最大、超长、特殊字符、unicode、负。标当前哪些会失败。5. 流程集成测试
下面是 {N 组件} 流程。请写 3 个集成测试：golden path、每步注入 1 个失败、恢复。
{粘贴}6. Mock vs 真
为 {feature} 建议：哪些依赖 mock、哪些保真。各按稳定 + 速度权衡说明。7. 快照测试审视
下面是现有快照测试。每个：有用还是噪声？建议替换或删除。
{粘贴}8. flaky 测试诊断
测试 {name} flaky。可能原因排序：网络、时序、共享状态、随机性、顺序。读测试与被测；识别最可能原因 + 修。
{粘贴}
9. API endpoint 测试
For the endpoint `{METHOD /path}` (handler pasted below), write integration tests in {framework} covering: (1) happy path with valid auth, (2) 401 unauth, (3) 403 wrong role, (4) 400 invalid body — name the specific invalid field, (5) 404 resource missing, (6) idempotency under retry (same key, second call). Tests must seed/teardown DB state per case.
{paste handler + schema}
可替换变量： framework（supertest+vitest、pytest+httpx 等）
优化建议： 若有 OpenAPI / Zod schema 也一起贴，AI 会自动派生非法输入用例。
10. React / UI 组件测试
For the React component below, write tests in {framework, e.g. RTL + vitest}. Cover: (1) renders given a typical prop set, (2) calls the correct callback on user interaction, (3) handles loading state, (4) handles error state, (5) accessibility — focusable, labelled, role-correct. Test by what the USER sees, not by component internals.
{paste component}
11. 测试金字塔平衡
测试套件臃肿却无效时跑。
Below is my test directory layout + a list of test files (paste). Analyze the test pyramid: ratio of unit / integration / e2e. Identify (1) where the pyramid is inverted (too many e2e), (2) tests that should be pushed down (e2e → integration → unit), (3) duplicate coverage between layers, (4) 5 specific test moves that would cut CI time by ≥30% without losing safety.
{paste tree + sample tests}12. 无工具找覆盖缺口
Don't run coverage tools. Below is the module under test + its current test file. Qualitatively identify: (1) the 3 branches with no test coverage, (2) any error path that isn't exercised, (3) any data shape used in production but not in tests, (4) the 5 highest-ROI tests I should add this week, ranked by likelihood-of-bug × user-impact.
Module: {paste}
Tests: {paste}13. 测试命名与结构清理
Below are 20 of my test names + bodies. Rewrite for readability: (1) name format `describe<unit>().it<scenario>().expect<outcome>`, (2) remove "tests" / "should" prefixes that add no info, (3) collapse duplicated setup into a `beforeEach`, (4) flag any 2 tests that are testing the same thing and suggest a merge.
{paste tests}容易踩的坑
- 测试逐步镜像实现
- 为”100% 覆盖”不测行为
- flaky 留在 main
- 修完 bug 再写测试——回归保证丢了
- mock 掉你本该测的东西
优化技巧
- 一定声明 框架与断言库——否则 AI 会把 Jest 和 Mocha 语法混着用。
- 每条测试自问”它能抓什么 bug？“——答不上就删。
- 先写失败测试再修：在 main 上失败、在你分支上通过，才是真回归测试。
- 优先表驱动式生成 Prompt（一行一个 case），易扩展低重复。
- Claude Code / Cursor 让 agent
Read邻近测试，风格匹配；贴片段式生成的测试在 PR 里很违和。 - 单次 Prompt 测试数控制在 8-10 内，更多 AI 会改个变量名复制语义。
- 生成的测试先在独立分支跑，错的测试合到 main 会污染整个团队 CI。
FAQ
- 怎么避免 change-detector 测试？: 在 Prompt 里描述行为契约（“返回去重排序的字符串”），不要描述实现细节。重构后还应该过。
- 该指定什么测试框架？: 用项目已有的。混框架徒增认知负担、CI 也会坏。打开一个现有测试文件，把 import 行贴进 Prompt 即可。
- AI 该 mock 还是用真实依赖？: 外部（HTTP / 支付 / 邮件）mock，进程内（解析 / 格式化 / 纯函数）保真。在 Prompt 里写明这条规则，默认值会变。
- AI 能识别 flaky 测试吗？: 有时能。模板 8（flaky 诊断）把测试 + 被测代码一起贴效果最好；只凭名字”猜 flaky”基本是瞎猜。
- 一个函数写多少测试？: happy path + 3 个边界 + 1 个非法输入是基线。出现已知 bug 才补对应的 case。
- 为什么我改坏了代码 AI 测试还是过？: AI 在测它脑中的代码，不是你的代码。改一行验证：还过就说明测试是噪声。用模板 12 找缺口。