测试金字塔不是教条：哪些该写单测，哪些该写集成

「测试覆盖率 80%」是个漂亮指标，但覆盖率高不等于没 bug——很多 bug 在模块之间。

合理的分配是按风险：核心逻辑写单测，跨服务边界写契约测试，关键路径写少量端到端。

先说结论

核心逻辑单测，模块交互集成测试，用户路径端到端少量。 覆盖率作为参考，不作为目标。

• 纯函数与业务规则：单测覆盖边界值
• 数据库与外部依赖：集成测试用容器
• 跨服务：契约测试锁接口形状
• 端到端只覆盖 3-5 条主流程

先把问题说清楚

测试的价值是「改代码时敢改」。如果一个测试跑一次要十分钟，没人会在提交前跑。

所以测试金字塔的底层逻辑是「反馈速度」：越快的测试越多，越慢的越少。

具体怎么做

按顺序执行，每步都验证完再进下一步：

• 先列关键路径：登录、下单、支付、核心计算
• 为纯逻辑写单测，覆盖边界与异常输入
• 用 Testcontainers 起真实数据库做集成测试
• 为跨服务接口写契约测试
• 端到端只保留主流程，放进 nightly

参数与成本对照

把关键数值摊开，方便判断该选哪条路：

几个容易踩的坑

下面这些是最常见的错误做法：

• 为了覆盖率写「调用一下不报错」的测试
• 所有测试都连真实第三方 API：慢且不稳定
• 端到端测试依赖固定数据：互相干扰
• 测试与实现耦合：改实现就要改一堆测试

最后补两句

判断测试好不好只有一个标准：它能不能在重构时保护你，而不是阻碍你。

工具是手段，理解机制才是能力。命令记不住没关系，知道「该看什么」就够了。