自动化测试 开发者测试:可测试性是设计出来的

horance · December 31, 2020 · 100 hits

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

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

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

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

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

分层架构

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

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

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

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

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

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

设计边界

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

边际效应

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

边界等同

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

设计优先

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

测试金字塔

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

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

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

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

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

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

「软件匠艺社区」旨在传播匠艺精神,通过分享好的「工作方式」,让帮助程序员更加快乐高效地编程!

No Reply at the moment.
You need to Sign in before reply, if you don't have an account, please Sign up first.