开发者测试：可测试性是设计出来的

谈开发者测试，为什么又要谈设计呢？这是一个有意思的问题。在切入这个主题之前，先看一个“完美架构图”的问题。

架构是完美的，实现是骨干的

我相信你肯定看过无数多个类似这样的架构图，每个框框都排布整齐，而且显得特别高大上。

引自：架构就是画框框？熊节

但是，实际的系统实现真的是这样吗？未必。系统往往充满了各种变化、约束、限制和条件，这些隐式的概念往往是不能“公诸于世”的。设计存在就是为了控制住系统实现的复杂度，应对软件的变化，并将这些隐式的概念显式化。

但是，我们也不能否认架构存在的意义，至少它利于个体之间的交流，利于与客户的沟通，并在更高维度的角度看待问题，并指导进一步的系统设计和实现。

分层架构

理论上，任何复杂的系统都可以用一个main函数实现，但事实上没人那么干，分层架构便是一种最朴素的系统分解和组合的架构思维，并符合大部分人的心智模型。

分层架构

分层架构最大的好处在于提供了层间抽象和隔离的机制，并非常容易在工程上保证层间的契约不被破坏。例如，分层架构遵守单向依赖原则，当有人违背架构原则而引入循环依赖，采用一些架构看护的工具，使能自动检查这些行为的。

其次，分层架构有利于开展模块间并行开发和协作。每个模块只要边界清晰，便可以独立开发了。但是，任何的软件工程方法的实践，必然存在它的边际效应。

同层模块间依赖混乱、模块内实现一团乱麻，

这是很多系统实现的真实写照。虽然，层间调用和约定都得到了很好的约束和保证，但同层内的模块间的耦合程度极高，相互引用和依赖，缺失架构原则的约束和检查。

更有甚者，模块内实现基本都是基于全局变量的过程化设计，缺失最基本的封装。在面临变化的时候，要么就是堆砌if-else，要么大面积拷贝代码，修修补补，导致系统实现的耦合度急剧攀升，最终将系统成功演进为典型的“腐化系统”。

系统实现的现状

设计边界

当我们确定了设计的边界和范围，便自然地决定了软件工程效率提升的边界、独立测试的边界、独立构建的边界，及其独立可替换的设计边界。

设计边界

边际效应

任何流程、工具和机器提升效率的边界，约束在设计边界的最大效应内，无法跨代提升。唯有改进设计，将设计的边界往内迁移，相应的工程效率才能得到质的提升和飞越。

边界等同

设计边界即独立裁剪的边界，独立测试和独立交付的构建边界。如果层间之间的依赖是抽象的，那么层测试所依赖的其他层实现便可以替换为测试替身；如果层内模块之间是低耦合的，那么模块测试所依赖的其他模块也可以替换为测试替身；如果模块内类或函数之间是低耦合的，那么类或函数所依赖的其他类或函数也可以替换为测试替身。

设计优先

因此，可替换性(裁剪性)、可测试性是提前设计出来的，是由设计的边界决定的，这便是"Design for Testability"的原始初衷。

测试金字塔

因为设计的边界决定了测试的边界。正如上述的系统实现，如果将系统看成整体，其外部的依赖和可观察的行为是可以控制的，所以设计相应的系统测试，虽然复杂，而且极难构造，但它是一种较为可行的测试方案。所以，这也是遗留系统普遍采用的一种测试方案，产生了大量的ST用例。

层间接口也较为稳定，所以也可以构造出大量的IT用例；而层内模块之间耦合程度逐渐增大，所以CT用例越来越少；随着设计边界的边际效应的消失，模块内的单元测试构造成本很高，或测试用例很脆弱，大部分系统实践单元测试最终走向了不归路。

最终，实际的测试金字塔是倒立的，或呈现菱形。与理想的测试金字塔刚好相反或背道而驰。

测试金字塔

理论上，UT是容易构造的，而且反馈是急快的，而且应该拥有绝对数量的UT用例。但是，现实并非如此，构造的UT并非易事；实现可能依赖庞大的全局变量，函数入参的结构体包含了繁杂的字段，而且函数实现朝夕令改，导致用例极为脆弱。

就其本质，这都是设计的问题。如果将每个全局变量进行合理的封装，那么内部逻辑变得更加稳定，测试用例的前置条件也变得容易构造；如果将不必要的依赖剥离，将实现最小化依赖，测试用例也会变得更加健壮；如果将依赖设计为抽象的，那么在测试中便可以轻松地替换为测试替身，提升可测试性。

总而言之，可测试性是设计出来的(Design for Testability)。