质量不是最后测出来的
很多团队的测试是这样的：开发写完功能，丢给测试同学最后验一遍，发现 bug 再来回扯皮。这种模式下，质量是「测出来的」，而且成本高、反馈慢。
质量内建要扭转的正是这件事：把质量做进开发流程的每一步，让问题在刚冒头时就被发现，而不是攒到最后一起算账。
越晚发现的问题，修复成本越高；把测试左移到开发过程中，是最划算的质量投资。
本文核心知识点
- 测试金字塔底层宽、顶层窄，分层搭配。
- 单元测试快而多，覆盖代码细节。
- 集成测试验证模块之间拼得对。
- 端到端少而精，守住关键业务路径。
- 质量门禁不合格就拦住，别往下走。
测试金字塔：为什么底层要宽
测试金字塔把测试分成三层，关键在于数量从底到顶递减：底层单元测试最多最快，往上集成测试少一些，最顶端端到端测试最少。这样搭配，反馈速度和覆盖广度才能兼顾。
| 层级 | 数量 | 特点 |
|---|---|---|
| 单元测试 | 最多 | 快、便宜、定位准 |
| 集成测试 | 中等 | 验证模块协作，略慢 |
| 端到端测试 | 最少 | 覆盖真实流程，慢而脆 |
反过来，如果把大量测试堆在顶端，就成了「冰淇淋甜筒」：跑一次要很久，一坏还难定位，团队很快就不想跑了。
单元测试：快而多，覆盖细节
单元测试针对最小的代码单元——一个函数或一个类——单独验证它的行为。它跑得快、数量多，是金字塔最宽的底座。
# 单元测试关注一件小事
输入一个边界情况
断言它返回预期结果
# 单元测试要：快、独立、只测一个行为
# 依赖外部的部分用替身隔开，别让它变慢变脆。- 写得快、跑得快，可以频繁运行。
- 失败时一眼定位到哪个函数出了问题。
- 把边界情况和常见错误都覆盖到。
底座够宽，团队才敢频繁改代码——因为改错了，立刻就有单元测试红给你看。
集成测试：验证模块拼得对不对
单个模块都测对了，拼在一起却可能出问题：接口对不上、数据传错、顺序乱掉。集成测试就是验证几个模块协作时是否如预期工作。
| 它关心 | 它不纠结 |
|---|---|
| 模块之间的接口是否对得上 | 单个函数的内部细节 |
| 数据流转是否正确 | 每个分支都走到 |
| 跟真实依赖是否配合 | 替代单元测试 |
集成测试比单元测试慢一些，所以数量适中，聚焦在模块交界这些容易出问题的地方。
端到端测试：少而精守关键路径
端到端测试从用户视角走完整条业务流程，最接近真实使用，但也最慢、最容易因为界面一点点变化就挂掉。所以它应该少而精，只守住最关键的几条业务路径。
# 端到端测试该覆盖什么
- 用户最核心、最值钱的那几条流程
- 一旦出错影响最大的关键路径
# 不要试图用端到端测试覆盖所有边角
# 那是单元和集成测试该干的事。端到端测试像保安：岗哨不用多，但必须站在最关键的几个路口。
质量门禁：不合格别往下走
测试写得再好，如果不强制执行，也会被绕过。质量门禁把「测试通过」变成合并和发布的硬条件：该跑的测试没过，流水线就拦住，别带病往下走。
- 关键测试失败，不允许合入主干。
- 覆盖率掉到阈值以下，给出提醒。
- 门禁是绕不开的，而不是写在文档里。
门禁把质量要求固化进流程，团队不需要靠自觉，系统会自动守住底线。
让质量成为默认而不是收尾
测试金字塔和质量门禁的最终目的，是让质量内建进开发流程，成为每次提交的默认状态，而不是发布前才补的一道手续。
- 底座宽厚，改代码心里有底。
- 门禁自动把关，问题早暴露。
- 团队从「怕破坏」变成「敢频繁改进」。
当质量成为默认而不是收尾，团队的交付速度和信心才会一起上来。