每个团队都见过那张三角形示意图：底层铺满单元测试，往上是少量的集成测试，顶端点缀几个端到端测试。但实际运行的测试套件往往是另一副模样——同一段业务逻辑，被单元测试、集成测试、接口测试、UI测试重复覆盖。推个分支，CI 跑二十分钟，最后因为某个随机挂掉的用例重新触发一次。

金字塔概念本身没错，错的是大多数团队对它的执行。

打开网易新闻 查看精彩图片

一种常见的声音认为：“用单元测试兜底还不够，在同一块逻辑上再叠一层集成测试，最后用端到端测试再过一遍，这样才安心。” 单看覆盖率报表，这种做法确实显得全面。但从工程成本看，这正是让 CI 变得越来越臃肿的源头。

打开网易新闻 查看精彩图片

反过来看，真正能让金字塔产生信心的设计，并不靠横向堆叠。它的思路更像一颗洋葱——中心是数量最多、跑得最快的用例，外层逐层包裹，每一层只负责验证它独有的那一份关注点。内层已经确认过的逻辑，外层不再重复检验。当每一个层级都只做自己该做的事时，重构内部实现就不会连带外层测试一起崩溃，慢速的外部依赖也不会被大量调用来复验本该在内存里跑完的断言。

这套结构的中心是后端用例层。所有外部依赖被藏进由应用自身定义的接口背后，测试时用内存替身替换真实适配器，协作图是真实的，底层运行时是纯内存的。这里没有数据库，没有 Redis，没有任何需要启动的外部环境。一个用例只验证领域逻辑本身，把适配器的正确性交给属于它们自己的测试层级。从这个中心向外，每一层都信任内层的验证结果，只负责件拼装后的连通性，而不重走内层已经覆盖的路径。

打开网易新闻 查看精彩图片

最外层的自信，来源于内层没有越界。