如何生成单元测试并保证覆盖完整？

核心回答

生成单元测试应从需求和可观察行为出发，先列出必须成立的规则、失败条件与边界，再让工具或 AI 提出用例和测试代码。覆盖率能发现遗漏执行路径，但无法证明业务覆盖完整；“100% 行覆盖”也可能只有很弱的断言。

更合理的目标是：关键契约有明确预期，主要分支和高风险边界被覆盖，测试能在实现出错时失败，并且执行稳定、维护成本可控。

如何生成有用的测试

先整理输入、输出、状态变化和外部依赖。例如优惠计算要覆盖最低金额前后、封顶前后、无优惠资格、空订单、重复应用优惠以及金额精度；不能只让 AI 按现有实现顺着生成几个正常例子。

把需求、接口契约、现有测试风格和必要的依赖说明交给 AI，要求它先提出测试点。人工或独立规则核对预期，再生成参数化测试。时钟、随机数和外部服务应可控；Mock 用于隔离不属于本单元的依赖，但要检查交互和返回行为是否符合真实契约。

断言既要看返回值，也要看错误、状态变化和副作用边界。例如失败时库存没有扣减，重复请求没有产生第二条业务记录。预期值最好来自规格、独立计算、已确认案例或参考实现，而非把待测函数的输出复制成标准答案。

如何发现覆盖缺口

• 行为清单：把业务规则、权限、状态迁移和异常处理对应到具体用例，检查哪些规则还没有保护。
• 行与分支覆盖：定位未执行代码及真假分支，特别关注短路条件、循环零次与多次、异常分支。覆盖报告是补查线索，不是业务正确性的证明。
• 变异测试：尝试将比较符、返回值等做小修改，检查现有断言是否能发现。未杀死的变异可能提示断言弱，也可能是等价变异，需要分析。
• 真实故障回归：把已修复问题的最小反例保留下来，并确认修复前失败、修复后通过。

单测之外还缺什么

函数单测通过，不能证明数据库事务、SQL、序列化、配置和服务协作都正确。跨边界风险应补集成或端到端测试；性能和并发问题需要相应验证。生成测试还要实际编译、执行，检查是否偶发失败、是否误改断言迁就实现。

面试中可以说明覆盖策略和已有证据，但不应承诺有限测试“证明完全无遗漏”。更有说服力的是指出哪些关键风险已经覆盖、哪些仍需其他层次验证。

参考资料