编程开发 编辑复核
单元测试用例生成器
按行为契约生成正常、边界、错误和回归测试，并明确哪些断言需要人工确认。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名测试工程师。请根据行为契约设计测试用例，优先覆盖用户可观察的结果，而不是内部实现细节。
输出：输入、前置条件、预期结果和优先级的测试矩阵；正常、空值、边界、重复请求、权限、网络失败和兼容数据；与当前测试框架一致的代码草案；需要 mock 的外部依赖；仍然缺少的验收条件。
如果代码上下文不足，不要猜函数签名；先列出待确认问题。不要为了提高覆盖率而写只断言实现细节的测试。
行为契约：{{contract}}
待测代码：{{code}}
测试框架：{{framework}}
已有测试：{{existing_tests}}HOW TO USE
使用说明
- 把生成的用例先和产品验收标准对齐，再写进测试文件。
- 测试失败时让模型解释证据，不要直接让它改断言使测试变绿。
WHEN IT FITS
适用判断
适合这些情况
- 函数逻辑清晰但分支多，手写测试用例容易漏。
- 你能提供函数实现和依赖的类型定义。
- 需要补齐边界和异常路径的覆盖。
换个做法更好
- 你要的是功能层面的测试场景：用《功能测试用例生成器》。
- 函数依赖大量外部状态：生成的测试会充满 mock，维护成本比价值高。
- 代码本身还在频繁变动：测试写完就要重写。
FAILURE MODES
常见翻车与修正
- 生成的测试只覆盖正常路径，异常分支没测。
要求先列出所有分支和边界条件，再逐条生成用例，并标注哪些分支没有覆盖到以及原因。
- 测试断言的是实现细节，稍微重构就全红。
要求断言函数的输入输出契约，不断言内部调用次数和私有状态，除非那本身就是契约的一部分。
- 用了项目里不存在的测试框架 API。
把你的测试框架、版本和一个现有测试文件粘进输入，要求生成的代码风格与之一致。
ACCEPTANCE
怎么判断输出合格
- 正常路径、边界值和异常分支都有用例。
- 断言的是输入输出契约，不是实现细节。
- 代码能直接在你的项目里跑通，框架用法正确。
- 明确标出了未覆盖的分支和原因。
SAFETY BOUNDARY
使用边界
- 生成的测试可能只是把当前实现的行为固化下来，包括其中的 bug；断言要对照需求而不是对照代码。
- 测试里不要写入真实的密钥和账号，即使是测试环境的凭据也会随仓库长期留存。