写点什么

“TDD 就是死亡”?我要为单元测试辩护

作者:Guilherme Ferreira

  • 2023-01-09
    北京
  • 本文字数:2831 字

    阅读完需:约 9 分钟

“TDD就是死亡”?我要为单元测试辩护

在 2014 年的时候,David Heinemeier Hansson在软件开发界引起了轩然大波。他在RailsConf的台上公然宣布“TDD就是死亡”。

 

这是个大胆的举动,但他也成为了很多不满于测试的人所寻找的领头人。很多人选择了跟随,开发者们就此分成了两个阵营。

 

当时所掀起的新浪潮一路带我们到了今天,单元测试不再重要,集成测试占据上风。Mike Cohn 所提出的著名测试金字塔如今被重塑为菱形形状。推动这股浪潮的因素并不唯一,在对现有测试实践不满的背后,或许并不难找到许多原因。

 

这种情况常常伴随固化的实践传播、缺乏的正确指导,以及沉溺的抽象思维出现。人人都试图做到最好,不断尝试、失败,再尝试,直到有人能打破锁链,开拓不同的道路,一条承诺通往低维护性测试套组的道路。

 


什么是最好的方向?


即使是在新领域,我们也很容易遗忘历史,这是我在这个行业中所学到的事。飞速发展的步伐让我们相信过去没有答案,而未来充满奇迹。我不知道未来会如何,但我相信我们总会倾向于追寻创新而非寻找信息。

 

或许下面这些问题能让很多质疑用测试菱形替代金字塔的声音:

  • 问题是由单元测试或单元测试编写所引起的吗?

  • 集成测试是否应用于需要的组件?

  • 我的误解是否导致了多处相同的断言?

  • 我是通过测试优化设计,还是围绕现有设计进行测试?

 

寻根  


答案或许又一次藏在了过去。

 

那么在集成测试上,历史能告诉我们什么呢?历史中,集成测试是不同开发单元一同测试的阶段。这些单元独立开发,且通常来自不同团队。在这一阶段,我们要确保的是所有接口的实现和运行正常。

 

如今的集成测试常常用于同一团队所开发的代码单元,这就意味着每个源码文件都是一个系统边界,相当于每个代码文件都是由同一个自主团队开发一样,模糊了单元测试和集成测试之间的界限。

 

因此,我们可以断定,集成测试与单元测试之间区别的根源是个错误。认定集成测试是用于团队之间测试,而单元测试是用于单一团队测试,这种区分观念本身便是不对的。我们所要解决的果正是自己造下的因。

 

我们应当明确这二者的界限,明确开发团队之间的界限而非层次。界限的明确会让你从新的角度看待系统的角色,以及它与其他领域的交互。类似于 Alistair Cockburn 所描述的六边形架构,后者也被称作是“端口与适配器”。在他的描述中,系统拥有里外两个面,而我们要做的,就是通过明确定义的边界来连接这两个面。

 

这有什么用呢?正是这个内外层的关系,明确了单元测试与集成测试之间的关系。单元测试负责从外向内地测试界限,而集成测试则是从内向外地对边界测试。具体来说,集成测试确保了适配器、网关和客户端,这些负责连接其他开发单元(如 API、插件、、数据库和模块)之间关系的正常运作。

 

针对行为的测试


“单元测试”中的“单元”是什么?单元是指行为的单元。这段定义中完全没有提到过任何针对单一文件、对象,或者函数的测试。那么,为什么编写针对行为的测试很难?

 

多数测试类型都会遇到的问题来自软件结构和测试之间的紧密联系,其中开发者忽视了测试目标,并以透明盒(有时也被称作是白盒)的方式应对测试。透明盒测试是指内部设计时以系统正常运作为目标,常见于单元测试。但透明盒的问题在于,测试往往会过于细化导致产生大量用例,而这些用例又与底层结构紧密耦合,给维护增加了难度。

 

人们对单元测试的不爽部分来源于此。而集成测试由于更多地脱离底层的设计,受重构的影响往往比单元测试要小。

 

我更倾向于从另一个角度看问题。这一点是集成测试的优势,还是由透明盒测试所带来的问题?如果我们以基于行为的不透明盒(有时也被称作黑盒)方式进行单元测试,那么结果是否一样或更好?

 

人们常常以为不透明盒测试只能应用于系统的外部边界,但这是不对的。我们的系统是由许多边界组成,有些可以借助通信协议访问,有些可以通过进程中的适配器扩展。这些适配器都有自己的边界,可以通过基于行为的方式进行测试。

 

模拟:孤注一掷


透明盒测试通常大量使用模拟(mock),可一旦过度依赖模拟,测试便会更难维护。也许这就是 Mark Seemann 所说的“桩(stub)和模拟破坏了封装”。在正视这类由过度使用模拟所带来的问题后,厌恶、甚至不惜一切代价地避免模拟是很正常的。仅使用 API 的测试通常会导致对模拟的过度依赖。

 

但问题又回到了最初,这是否真的是由模拟或对模拟的误用导致的呢?

 

模拟和桩或许更难维护,但它们的存在是有意义的。它们让测试更快也更稳定,我们需要掌控它们,且不在必要之外滥用模拟和桩。

 

减少代码的公共表面


透明盒测试的另一弊端在于其会导致更多代码的暴露。验证器、映射器,以及其他可能的内部实现细节都会因为测试的缘故暴露在公共契约(contract)内。任何使用 Java 或 C#的人都知道接口在代码库中的普遍程度。仅仅为了模拟一个依赖,开发者很可能会引入一个新接口。

 

可被从外部访问的代码将会更难变动,测试也将成为必须项,让代码的可维护性受到质疑,在没有大量重写单元测试的情况下,重构几乎成为不可能。乍一看,这一问题似乎利于集成测试;集成测试更关注于外层,不会暴露很多的实现细节。

 

但还是那个问题,这究竟是单元测试的问题,还是我们在实现单元测试方式的问题?如果我们以不透明盒的形式进行单元测试,无视内部设计方式,仅关注于消费者需求,或许我们会收获更小的契约,一个更易于测试的契约,更少的测试量,以及更便于维护的测试。

 

以架构为指导原则


测试常常是围绕架构进行的。我们常常在系统设计完成之后才会考虑测试,但这也会让系统测试的难度更上一层楼。多层架构中这种情况屡见不鲜,对数据访问技术的依赖让领域层的单元测试更加繁复。

 

采用测试隔离的架构可以轻松避免这种问题。无论是六边形架构还是干净架构(Clean Architecture),可选的有很多。这类架构的构建是独立于设备的,所有基础设备依赖都会通过依赖配置接入系统。架构的单元测试会更加舒适,并引导集成测试到适当的应用下:测试连往外部的适配器。

 

集成测试的适配器会为我们的测试策略带来一个薄弱点。在所有组件相连的情况下进行集成测试,将收获测试在配置和组合方面的优势,显然这是我们想要的目标。当然我们也可以继续在组件全部相连的情况下测试,但这些测试只会是“烟雾弹”,不需要测试所有的边界情况,从而导向更稳定,也更可靠的测试。

 

结论


质疑行业中的固有观念很重要,但在质疑之前先充分理解这些观念也同样重要。

 

我们都知道历史是不断重复的,过去会带给我们关于将来决定的信息。但我们也应该明白同样的错误将会不可避免地一遍遍发生。这是人之本性,是否能规避这些错误将取决于我们自己。测试策略也是这些不断重复的错误之一。我们要面对这些由于信息或知识匮乏,以及错失已有优秀实践而导致的痛点。

 

测试与架构是息息相关的。我们需要在设计架构时不忘测试情况,在我们追寻优秀测试策略时,单元测试仍会是我们可用的工具。


原文链接:

https://www.infoq.com/articles/unit-tests-testing-pyramid/


相关阅读:

个性化测试流程,不搞一刀切

只擅长构建软件是不够的,我们必须擅长构建可测试的软件 | QCon

2023-01-09 08:005827

评论

发布
暂无评论
发现更多内容

react中的diff算法,通俗易懂的解读

flyzz177

React

JAVA代码审计之java反序列化

Java-fenn

Java

架构实战营模块八作业

zhihai.tu

探索商业细分市场,中海打造北京南中轴首座家庭购物中心 | 商业地产

E科讯

JS 模块化 - 02 Common JS 模块化规范

Java-fenn

Java

[架构实战]学习笔记

爱学习的麦子

Kafka:可靠!可靠!还是xx的可靠!

程序知音

Java kafka 编程 后端技术

基于electron+vue+element构建项目模板之【自定义标题栏&右键菜单项篇】

Java-fenn

Java

Alibaba架构师内部最新发布SpringCloud开发手册,Github限时开源

Geek_0c76c3

Java 数据库 spring 开源 架构

阿里高工内产的 SpringBoot 实战派手册仅发布一天霸榜Github

Geek_0c76c3

Java 数据库 开源 架构 开发

VScode中配置 C/C++ 环境

c vscode 9月月更

名震GitHub!字节跳动内部顶级数据结构刷题学习笔记根本停不下来

程序知音

Java 数据结构 算法 后端开发 数据结构与算法

2022互联网寒冬期这套Java面试突击宝典助你破局,直击大厂!

了不起的程序猿

Java 编程 程序员 编程语言 java编程

阿里顶配版 Spring 全家桶高级笔记+学习路线图+硬核资料库,跪着啃完了。。。。

Java-fenn

Java 程序员 面试 Java面试题

MySql的InnoDB的三层B+树可以存储两千万左右条数据的计算逻辑

Java-fenn

Java

ESP32-C3入门教程 网络 篇(二、 Wi-Fi 配网 — Smart_config方式 和 BlueIF方式)

矜辰所致

wifi ESP32-C3 9月月更 BlueIF Smaart_config

20 条 Chrome DevTools 使用建议,盲猜这几个你不知道~

掘金安东尼

前端 9月月更

架构师的十八般武艺:安全架构

agnostic

安全架构

AWS CloudFormation简介

冯亮

DevOps AWS Cloud IaC

使用 WebAssembly 打造定制 JS Runtime

Java-fenn

Java

认识RocketMQ4.x架构设计

Java-fenn

Java

VS Code settings.json 10 个高(装)阶(杯)配置!

掘金安东尼

9月月更

抽丝剥茧看时间序列预测

CnosDB

IoT 时序数据库 开源社区 CnosDB infra

国际聋人周 | 聋健人群无界融合,看见手语的力量

HarmonyOS SDK

手语

初识设计模式 - 原型模式

Java-fenn

Java

安卓项目架构设计-梳理现有项目的混乱

Java-fenn

Java

ESP32-C3入门教程 网络 篇(一、 Wi-Fi 使用入门 — 初始化及STA、AP模式)

矜辰所致

wifi ESP32-C3 9月月更

重磅来袭!腾讯T7手写高并发实战手册,GitHub热度一直不下

Geek_0c76c3

Java 数据库 spring 开源 架构

华为帐号自拟形象上线 打造手机里的另一个你

HarmonyOS SDK

架构营第一期作业

许四多

如何保证数据库和缓存双写一致性?

Java快了!

“TDD就是死亡”?我要为单元测试辩护_软件工程_InfoQ精选文章