2月5-7日QCon全球软件开发大会携手100+位大咖讲师落定北京,点击查看完整日程>> 了解详情
写点什么

“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:003147

评论

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

前端之算法(八)贪心算法

Augus

算法 8月日更

全靠阿里内部(珠峰版)Java面试笔记,成功拿下12家大厂offer

编程菌

Java 编程 程序员 阿里 计算机

阿里P8整理的《百亿级并发系统设计》实战教程,实在是太香了

编程菌

Java 编程 程序员 阿里 计算机

”微博评论“的高性能高可用计算架构

feitian

平台利用大数据割韭菜,消费者为何沦为砧板上的鱼肉

石头IT视角

大一被调剂到计算机,对电脑根本不了解,只会上网聊天,如何杜绝

hanaper

c++ 数据结构算法

架构实战营模块五作业

袁小芬

有了阿里人的并发图册+JDK源码速成笔记,我终于不慌内卷了

编程菌

Java 编程 程序员 面试 计算机

架构实战营作业 M05

Shawn Liu

模块五作业:设计微博评论的高性能高可用计算架构

Felix

面试必考:秒杀系统如何设计?

苏三说技术

系统设计 高并发 秒杀

真的香!Github一夜爆火被各大厂要求直接下架的面试题库也太全了

编程菌

Java 编程 程序员 面试 计算机

【大咖直播】Elastic Security 安全管理实战工作坊

腾讯云大数据

大数据 elasticsearch

QDS curl 安装

耳东@Erdong

curl 8月日更 qds

【SpringCloud技术专题】「Feign技术专区」从源码层面让你认识Feign工作流程和运作机制

洛神灬殇

OpenFegin spring-cloud Fegin 8月日更

从零开始的SRC挖掘

网络安全学海

黑客 网络安全 信息安全 渗透测试 漏洞挖掘

没有捷径的中国AI“直道超车”之路:百度世界大会2021的智能时代启示录

脑极体

Python Web 菜谱项目再次前进一步,从应用层了解内置用户认证系统

梦想橡皮擦

8月日更

常见酒店行业术语

IT蜗壳-Tango

8月日更

架构训练营 模块五

小卷儿

Flink 和流式应用运维(十-中)

数据与智能

flink 调度 检查点

Jira Automation 探索与实践

GrowingIO技术专栏

项目管理 自动化 Jira

微服务的演进之路

卢卡多多

微服务 8月日更

【ClickHouse】 核心特性

LeifChen

Clickhouse 8月日更

PAI:一站式云原生AI平台

阿里云大数据AI技术

[架构实战营一期] 模块五作业

trymorewang

架构实战营

阿里架构师花近十年时间整理出来的Java核心知识pdf(Java岗)

编程菌

Java 编程 程序员 面试 计算机

Nacos-spring-boot 0.2.10 发布,全面支持 Nacos2.0

阿里巴巴中间件

云计算 开源 云原生 中间件

模块五作业

king

网络攻防学习笔记 Day109

穿过生命散发芬芳

网络安全 8月日更

干货来袭!阿里技术官甩出的内部首推分布式系统开发笔记太顶了

编程菌

Java 编程 程序员 面试 计算机

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