查看原文
其他

有关单元测试的 5 个建议

Python猫 2022-04-12

The following article is from piglei Author piglei

作者:piglei   

来源:piglei   

虽然好像人人都认为单元测试很有用,但在实际工作中,有完善单元测试的项目仍然是个稀罕物。大家拒绝写单元测试的理由总是千奇百怪:“项目工期太紧,没时间写测试了,先这么用吧!”“这模块太复杂了,根本没法写测试啊!”“我提交的这个模块太简单了,看上去就不可能有 bug,写单元测试干嘛?”

这些理由乍听上去都有道理,但其实都不对,它们代表了人们对单元测试的一些常见误解。

1.“工期紧没时间写测试”:写单元测试看上去要多花费时间,但其实会在未来节约你的时间;2.“模块复杂没法写测试”:也许这正代表了你的代码设计有问题,需要调整;3.“模块简单不需要测试”:是否应该写单元测试,和模块简单或复杂没有任何关系。

在长期编写单元测试的过程中,我总结了 5 个与单元测试有关的建议,希望它们能帮你更好的理解单元测试这回事。

1. 写单元测试不是浪费时间

对于从来没写过单元测试的人来说,他们对单元测试的看法往往是这样的:“写测试太浪费时间了,会降低我的开发效率。”从直觉上来看,这个说法似乎有一定道理,因为编写测试代码确实要花费额外的时间,如果不写测试,这个时间不就省出来了吗?

但真的是这样吗?不写测试真能节省时间?让我们看看下面这两个场景。

假设你在为某个博客项目开发一个新功能:支持在文章里插入图片。在花了一些时间写好功能代码后,由于这个项目没有任何单元测试,于是你在本地开发环境里,简单测试了一会,确认功能正常后就提交了改动。一天后,这个功能被发布到了线上。

但令人意外的是,功能发布以后,虽然文章里能正常插入图片,但系统后台却开始接到大量用户反馈:所有人都没法上传用户头像了。仔细一查后才发现,由于你开发新功能时,调整了图像模块的某个 API,而头像处理功能恰好使用了这个 API。因此,新功能最后弄坏了八竿子打不着的头像上传功能。

“我写的代码,一般不测试,要测就在生产环境测”

如果这个项目有单元测试的话,上面这种事儿根本就不会发生。当单元测试覆盖了项目的大部分功能以后,每当你对代码做出任何调整,只要跑一遍所有的单元测试,绝大多数问题都会自动浮出水面。许多隐蔽的 bug 根本不会被发布出去,因为单元测试会将它们扼杀在摇篮里。

因此,虽然不写单元测试看上去节约了一丁点时间,但有问题的代码上线后,你会花费更多的时间去定位、去处理这个 bug。缺少了单元测试的帮助,你需要耐心找到改动可能会影响到的每个模块,手动验证它们是否工作正常。所有这些事儿所花费的时间,足够你写好几十遍单元测试。

另一个单元测试能节约时间的场景,发生在项目需要重构时。

假设你要对某个模块做大规模的重构,那么,这个模块是否有单元测试,分别对应着两种天差地别的重构难度。对于没有任何单元测试的模块来说,重构是地狱难度。在这种环境下,每当你调整任何代码,你都必须仔细找到模块的每一个被引用处,小心翼翼的手动测试每一个场景。稍有不慎,重构就会引入新 Bug,好心就会办出坏事。

而在有着完善单元测试的模块里,重构是件轻松惬意的事情。在重构时,你可以按照任何你想要的方式,随意调整和优化旧代码。每次调整后,只要重新跑一遍测试用例,几秒钟之内你就能得到完善和准确的反馈。

所以,写单元测试不是浪费时间,也不会降低你的开发效率。你在单元测试上花费的那点时间,会在未来的日子里,为项目的所有参与者节约不计其数的时间。

2. 不要总想着“补”测试

“先帮我 Review 下刚提交的这个 PR,功能已经全实现好了。单元测试我等会再补上来!”

在工作中,我常常会听到上面这句话。情况通常是,某人开发了一个或复杂或简单的功能,他在本地开发调试时,主要依靠手动测试,并没有同步编写功能的单元测试。但项目对单元测试又有要求。因此,为了尽早进入 Review 阶段,他决定把已实现的功能代码先提交上去,晚点再补上单元测试。

在上面的场景里,单元测试被当成了一种验证正确性的事后工具,对开发功能代码没有任何影响,因此,人们总是可以在完成开发后补测试。

但事实是,单元测试不光能验证程序的正确性,它还能极大的帮助你改进代码设计。但这种帮助有一个前提条件,那就是你必须在编写代码的同时,编写单元测试。当开发功能与编写测试同步进行时,你会来回切换自己的角色,分别作为代码的设计者和使用者,不断从代码里找出问题,调整设计。经历过多次调整与打磨后,你写出的代码会变得更好,更有扩展性。

但是,当你已经开发完功能,准备“补”单元测试时,你的心态和所处环境就已经完全不同了。假如这时,你在写单元测试时遇到了一些障碍,你会想尽各种办法来粗暴移除这些障碍,比如引入大量 Mock,或者只测好测的,不好测的干脆不测。在这种心态下,你最不想干的事,就是调整你的代码设计,让它变得更容易被测试。为什么?因为功能已经实现好了,再改来改去又得重新测,多麻烦呀!所以,不论最后的测试代码有多么别扭,只要能跑起来就好。

测试代码并不比普通代码地位低,选择事后补测试,你其实白白丢掉了用测试来驱动代码设计的机会。只有在编写代码时同步编写单元测试,你才能最大的享受到单元测试的好处。

我应该使用 TDD(测试驱动开发)吗?

TDD(测试驱动开发 Test-Driven Development 的首字母缩写)是由 Kent Beck 提出的一种软件开发方式。在 TDD 工作流下,要对软件做一个改动,你不会去直接修改代码,而是会先写出这个改动所需要的测试用例。

TDD 的大致工作流如下:

1.写测试用例(哪怕测试用例引用的模块根本不存在)2.执行测试用例,让其失败3.编写最简单的代码(此时只关心实现功能,不关心代码整洁度)4.执行测试用例,让测试通过5.重构代码,删除重复,让代码变的更整洁6.执行测试用例,验证重构7.重复整个过程

在我看来,TDD 是一套行之有效的工作方式,它很好的发挥出了单元测试驱动设计的能力,的确能帮助你写出更好的代码。

但在实际工作中,我其实很少宣称自己在实践 TDD。因为在开发时,我基本不会严格遵循上面的 TDD 标准流程。比如有时,我会直接跳过 TDD 的前两个步骤,不先写任何会失败的测试用例,直接就开始编写功能代码。

假如你从来没试过 TDD,我建议你可以了解一下 TDD 的基本概念,试着在项目中用 TDD 流程写几天代码。也许到最后,你会像我一样,并不会成为一名 TDD 的忠实信徒。但没准通过 TDD 的帮助,你能找到那个最适合你自己的开发流程。

3. 难测试的代码就是烂代码

在为代码编写单元测试时,我们常常会遇到一些特别棘手的情况。

举个例子,当模块依赖了一个全局对象(global object)时,写单元测试就会变得很难。全局对象的基本特征,决定了它在内存中永远只会存在一份。而在编写单元测试时,为了测试代码在不同场景下的行为,我们一定会需要用到多份不同的全局对象。这时,全局对象的唯一性就会成为写测试最大的阻碍。

再举一个例子,项目中有一个负责用户帖子的类 UserPostService,它的功能非常复杂,初始化一个 UserPostService 对象,需要提供多达十几个依赖参数。比如用户对象、数据库连接对象、某外部服务的 Client 对象、Redis 缓存池对象等等。

这时,你会发现,你很难给 UserPostService 编写单元测试,因为写测试的第一个步骤就会难倒你:你创建不出一个有效的 UserPostService 对象。光是想办法搞定它所依赖的那些复杂参数,都要花费你大半天的时间。

所以我的结论很简单:难测试的代码就是烂代码。

在不写单元测试时,烂代码就已经是烂代码了,只是我们并不能很好的意识到这一点。也许在 Code Review 阶段,某个经验丰富的同事会在 Review 评论里,友善而委婉的提道:“我感觉 UserPostService 类好像有点复杂?要不要考虑拆分下?”但也许他也不能准确的说出拆分的深层理由,也许经过妥协后,这堆复杂的代码最终就这么上线了。

但有了单元测试后,情况就完全不同了。每当你写出难以测试的代码时,单元测试总会无差别的大声告诉你:“你写的代码太烂了!”不留不点情面。

因此,每当你发现很难为代码编写测试时,你就应该意识到代码设计可能存在问题,你需要努力调整设计,让代码变得更容易被测试。也许你应该直接删掉全局对象,仅在它被用到的那么几个地方,每次都手动创建一个新对象。也许你应该把 UserPostService 类,按照不同的抽象级别,拆分为许多个不同小类,把依赖 IO 的功能和纯粹的数据处理完全的隔离开来。

单元测试给了你一个评估代码质量的标尺。每当你写好一段代码时,你都能清楚知道代码到底写的是好还是坏,因为单元测试不会撒谎。

4. 像应用代码一样对待测试代码

随着项目的不断发展,应用代码一定会越来越多,测试代码也同样会随之增长。在看过许许多多的应用代码与测试代码后,我发现,人们在对待这两类代码的态度上,常常有着一些微妙的区别。

第一个区别,是对重复代码的容忍程度。举个例子,假如在应用代码里,你提交了 10 行非常相似的重复代码。那么这些重复代码,几乎一定会在 Code Review 阶段,被其他同事作为烂代码指出来,最后它们非得被抽象成函数不可。但在测试代码里,10 行重复代码是件稀松平常的事情,人们甚至能容忍更长的重复代码段。

另一个区别,是对代码执行效率的重视程度。在编写应用代码时,我们非常关心代码的执行效率。假如某个核心 API 的耗时,突然从 100 毫秒变成了 130 毫秒,会是个严重的问题,需要尽快被解决。但是,假如有人在测试代码里,偶然引入了一个效率低下的 fixture,导致整套测试的执行耗时突然变慢了 30%,似乎也不是什么大事儿,极少会有人关心。

最后一个区别,是对于“重构”的态度。在写应用代码时,我们常常会定期回顾一些质量糟糕的模块,在必要时做一些改善质量的重构工作。但是,我们却很少对测试代码做同样的事情——除非某个旧测试用例突然坏掉了,否则我们绝不去动它。

总体来说,在大部分人看来,测试代码更像是代码世界里的“二等公民”。人们很少关心测试代码的执行效率,也很少会想办法提升测试代码的质量。

但这样其实是不对的。如果人们对测试代码缺少必要的重视,那么测试代码就会慢慢腐烂。当项目的测试代码最终变得不堪入目,执行耗时以小时为单位计算时,人们从心理上就会开始排斥编写测试,也不愿意去执行测试。

所以,我建议你应该像对待应用代码一样,来对待测试代码。

比如,你应该关心测试代码的质量,经常想着把如何把测试代码写得更好。具体来说,你应该像学习项目 Web 框架一样,深入学习测试框架,而不只是每天重复使用测试框架最简单的功能。只有在了解工具后,你才能写出更好的测试代码。拿 Python 的测试框架 pytest 来说,假如你并不知道参数化测试 @pytest.mark.parametrize 的存在,那你就得重复许多相似的测试用例代码。

使用 parametrize 编写参数化测试

测试代码的执行效率同样也十分重要。只有当整套单元测试,总能在足够短的时间内执行完时,大家才会更愿意频繁的执行测试。在开发项目时,所有人能更快、更频繁的从测试中获得反馈,写代码的节奏才会变得更好。

总结一下,在项目开发的过程中,除了关注应用代码的质量与效率以外,你也应该对测试代码一视同仁,只有这样做,才能最大发挥出测试的能力,让项目保持活力。

5. 避免教条主义

说起来很奇怪,在单元测试领域,长期有着非常多的理论与说法。人们总是乐于发表各种对单元测试的见解,在文章、演讲以及与同事的交谈中,你常常能听到下面这些话:

•“只有 TDD 才是写单测的正确方式,其他都不行!”•“TDD 已死,测试万岁!”•“单元测试应该纯粹,任何依赖都应该被 Mock 掉!”•“Mock 是一种垃圾技术,Mock 越多,表示你的代码越烂!”•“只有项目达到 100% 测试覆盖率,才算是合格!”•…

人们乐于不断提出理论,也喜欢坚定不移的支持它们。但我的建议是:你应该了解这些理论,越多越好,但是千万不要陷入教条主义。因为在现实世界里,每人参与的项目千差万别,别人的理论不一定就适用于你,如果对任何理论盲目遵守,反而会给自己增加麻烦。

拿是否应该隔离测试依赖来说。我曾经参与过一个与 Kubernetes[1] 有关的项目,项目里有一个核心模块,主要职责是按规则组装好 Kubernetes 资源,然后利用 Client 模块将这些资源提交到 Kubernetes 集群中。

要搭建一套完整的 Kubernetes 集群特别麻烦。因此,为了给这个模块编写单元测试,从理论上来说,我们需要实现一套假的 Kubernetes Client 对象(fake implementation)——它会提供一些接口,返回一些假数据,但并不会访问真正的 Kubernetes 集群。用假对象来替换原本的 Client 后,我们就可以完全 Mock 掉 Kubernetes 依赖。

但最后,项目其实并没有引入任何的假 Client 对象。因为我们发现,如果使用 Docker,我们其实能在 3 秒钟之内,快速启动一套全新的 Kubernetes apiserver 服务。而对于单元测试来说,一个 apiserver 服务足够完成所有的测试用例,根本不需要其他 Kubernetes 组件。

通过用 Docker 来启动真正的依赖服务,我们不光节省了用来开发假对象的大量时间,并且从某种程度上,这样的测试方式其实更好,因为它会和真正的 apiserver 打交道,更接近项目运行的真实环境。

也许这时有人会说:“你这么搞不对啊!单元测试就是要隔离依赖服务,单独测试每个函数(方法)单元!你说的这个根本不是单元测试,你这个是集成测试(integration test)!”

好吧,我承认这个指责看上去有一些道理。但首先,单元测试里的单元(Unit),其实并不严格的指某个方法、函数,单元其实指的是软件模块一个行为单元,或者说功能单元。其次,某个测试用例应该被算做集成测试或单元测试,这真的重要吗?在我看来,所有的自动化测试只要能满足几条基本特征:快、用例间互相隔离、没有副作用,这就够了。

单元测试领域的理论确实很多,但这刚好说明了一件事,那就是要做好单元测试真的很难。要更好的实践单元测试,你要做的第一件事就是抛弃教条主义,脚踏实地,不断去寻求最合适当前项目的测试方案,那样才能最大的享受到单元测试的好处。

References

[1] Kubernetes: 一个流行的容器编排框架

Python猫技术交流群开放啦!群里既有国内一二线大厂在职员工,也有国内外高校在读学生,既有十多年码龄的编程老鸟,也有中小学刚刚入门的新人,学习氛围良好!想入群的同学,请在公号内回复『交流群』,获取猫哥的微信(谢绝广告党,非诚勿扰!)~


还不过瘾?试试它们




Python工匠:解析容器类型的门道

Python 工匠:让函数返回结果的技巧

Python 工匠:异常处理的三个好习惯

Python 工匠:编写地道循环的两个建议

Python 工匠:使用装饰器的技巧

Python 工匠:高效操作文件的三个建议


如果你觉得本文有帮助
请慷慨分享点赞,感谢啦

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存