一枚程序员眼中单元测试

网友投稿 675 2022-05-30

为了更好地阅读体验,欢迎访问博客原文

论测试的重要性

如今程序员群体赶上了中国最庞大的农民群体,大街上随便抓一把,十有八九是程序员,还一个刚从某国企离职报名参加软件培训班。我想码农的称号或许就是这么来的吧。

在外行人看来,程序员是一个成天对着电脑倒腾着代码、看着Terminal上行云流水般的打印、过着不修边幅的日子外加超负荷的码农。

在内行人看来,程序员是一个成天面对QA的"质疑"、PM的"夺命催"以及DEVs的"吐槽",扛着身心压力的苦行僧。

在我看来,程序员应该是:

手持神剑,心怀善念,胸有成竹、有理有据并且合情合理地跟QA、PM、DEV斗智斗勇的战士。

要摆脱QA的质疑、DEVs的吐槽以及PM的夺命催,除了那些不容易掌控的客观因素,我们可以从自身发力,加强自身的"核心肌群",呈现出自己的应有的专业态度,编写出高质量的代码,从而促成高质量的交付。

如何交付高质量的代码?

首先,我们可以摆出苦行僧的心态,平日里练就一身好把式:如Clean Code、Refactor、OOD及FOP。即便这样,牛逼哄哄的程序员也不敢说自己的代码百分之百没有缺陷。

怎么办,两个参考原则:

编写完代码多问自己一句:"真的可靠地完成目标了吗?" 怎么问,写个测试来提问。这便是 测试覆盖。

一枚程序员眼中的单元测试

编写代码之前先问自己一句:"怎么样才算完成目标了呢?" 怎么问,同样写个测试来提问。这便是 TDD + 测试覆盖。

测试能做什么

要知道测试能做什么,首先我们需要知道测试是什么(它在测什么)?它能给我们带来什么价值?以及人力成本那么昂贵,我们为什么还要花时间去编写这些上不了产品的测试代码?

程序员总喜欢倒腾点代码来开始一个话题:

这一小段测试代码所做的事情是在验证StringUtils#toUpperCase方法的功能正确性。

顺便用一句话来形容单元测试:

开发人员编写一小段代码,用于检验被检测代码的一个很小的、很明确的功能是否正确。

广义上的测试并不总是像上面这段代码这么简单,熟为人知的 测试金字塔 将测试分为三大类,单元测试位于测试金字塔底端,旨在传达单元测试应该来得更凶猛一些,而它们正是由开发人员亲手编写出来。本文也是围绕单元测试来开展。

测试的价值何在

经常听开发人员说:"我对我的代码非常有信心。"理由往往充分且单一:单元测试是老大,老大罩着我不怕。(当然,专业的QA始终能发现DEV很难察觉到的Defect,难免会惊起一脸狐疑:老大不灵了吗!回首代码,觉漏某一Case)。

所以单元测试能够增强你写代码的信心。都说自信是成功者必不可少的特质。当你对代码充满信心之后,你的潜能无形中被激发(你会发现你敲代码的速度都会变快),这样你工作效率的提高促使你更加轻松地完成工作。身心受益便会产生一连串良性的"蝴蝶效应"。

测试的两个无形价值就体现出来了:

1. 增强我们写代码的信心。 2. 让我们更加轻松的完成工作,身心收益。

再来说说有形的代码。缺陷减少了则证明你的代码质量提高了,代码质量衡量指标总离不开可读性、可扩展性、可维护性。这三个指标的增强反映了良好的代码整洁度、OO设计、模块化等。实践证明,这些良好的设计往往不是一蹴而就的,而当你为一个类或方法编写单元测试却举步维艰的时候,你就应该考虑去改良你的设计了。

理想情况下,编写完的代码应该是可以工作的。但现实并不那么美好,当你在验证代码正确性的时候遇到问题,你就不得不频繁地启用调式模式,而调试正是吞噬你宝贵时间的恶魔。此时我们要拔出单元测试这把神剑,使出浑身解数将恶魔驱赶到尘封的黑暗角落,从而缩减我们花在调式上的时间。

那么,测试的两个有形的价值也体现出来了:

3. 改良我们的设计。 4. 缩减我们花在调式上的时间。

在敏捷开发领域,文档(需求文档,详细设计文档等)是罕见之物。当一个新人半途加入项目的时候,在没有太多文档的情况下,阅读测试代码便是一个很好的开始。当然,前提是我们的测试代码必须是可靠的,并且具有良好的可读性。单元测试的第五项不可小觑的价值就被体现出来:

5. 测试即文档。

不写测试又如何

有一种声音:"单元测试代码写得再漂亮,也终究不是产品代码,在部署到生产环境时会被无情的抛弃掉!"

所以被这种声音迷惑的人开始信奉了长(测)话(试)短(少)说(写),短(甚)话(至)不(不)说(写)的信仰。这只是经过修饰得以传播的一种声音,而背后做支撑的总有那么几大派系。

无辜派

1. 我并不清楚代码的行为,你叫我怎么测试呢?2. 这些代码命名都能够通过编译啊!

个性派

1. 测试代码不是我的工作,这不应该由专门的人去做吗?2. 公司请我来是为了写代码,而不是写测试的。

同理派

1. 如果我让QA人员没有工作,那么我会觉得很内疚的!

仔细推敲这三大派系,甩出几个问题就能让这些借口不攻自破:

1. 如果连代码的行为都不清楚,写出来的代码意义何在? 2. 通过编译就代表能正常工作吗? 3. 你可以不写测试,但你写的代码不断被QA找出Defect,作为DEV名声信誉何在,难道写出可靠的代码也不是你的职责吗? 4. 公司的确不是雇你来写测试的,那公司是顾你来调试bug的吗? 5. 试问QA会喜欢一个交付的代码存在很多Defect的DEV吗?我想QA也宁愿代码可靠到让他ta"无事可做",从而去做一些功能测试、性能测试、验收测试等。

让我觉得值得一提的是常规派的看法:

1. 编写单元测试太花时间了,项目结束时再说吧!2. 运行测试时间太长了!

"编写单元测试太花时间了,等测试结束后再说" 听起来是一个很合乎情理的想法。而在软件开发项目上存在一个这样的魔咒:

一推再推的事情,往往都是不会去做的事情。

不去做的原因可能是重视度不够,被和谐掉了,也可能是最后想去做也没有时间去做。不管出于什么原因,不写测试存在潜在的风险。

实践证明,随着时间推移,产品的功能性的变化趋势受测试代码编写的时机的影响如下图所示:

好想法抵挡不住现实的打击,代码库随着项目的进展越发复杂,由于没有测试的保护,一些不良的设计偷偷溜了进来,代码越发娇气,慢慢地没有人敢去动它。最糟糕的结果可能是,DEVs顶着巨大交付压力,唯唯诺诺的写着代码,而灾难正在酝酿,交付最终失败。

所以只有当测试代码并行于产品代码,甚至可以采用TDD。测试的几大价值才有可能被体现出来,从而能够为我们的产品保驾护航。

另外,如果是因为不熟练而导致编写测试的时间太长,不妨记录一下自己每天花在定位问题和调试上的时间,做个对比,你会发现编写单元测试最终是会为你节省时间的。

就我个人经验,半TDD的编码方式,在一个Story上所花的总时间不会多余没有测试裸奔的代码。或许刚开始会觉得有点拖慢节奏,操练多了,它的威力就会彰显出来了。

测试也写了,可是运行时间太长了又带来了另一个苦恼?

细谈该苦恼可以单独写一篇文章了。我的确见过测试运行时间很长,每次验证一次跑上半个多小时。下面列举一些测试加速的实践:

1. 编写更多的单元代码来代替一些不重要的集成测试和UI测试。 2. 使用Mockito、JMock等工具模拟掉依赖。 3. 并行运行测试,前提是让测试之间保持相互独立。 4. 让CI服务器去跑更耗时的集成测试和UI测试。 5. 使用契约测试来代替微服务之间的集成测试。

单元测试运行时间是毫秒级别的,如果耗时过长,你就要留意是否存在内存泄漏、资源未释放、依赖过重或者不依赖容器而启动了容器的单元测试。

挥之不去的例外

编写单元测试是一项成本低却价值很高的活动。编写它不会花掉你太多的时间,而运行它更是毫秒间的事情。极限编程推崇者正在使用TDD的方式诠释着单元测试的价值和意义。

它能带给我们信心,改良我们的代码设计,提升我们(DEVs)的声誉,为代码库保驾护航,为高质量的软件交付提供保障。但它终究不是一颗银弹。我们编写单元测试也无非是一种价值的取舍,当它给我们带来的价值低于我们付出的成本时,我们就要保持警惕了,比如思考以下两个问题:

1. 在追求漂亮的测试覆盖率数字100%的时候,思考一下它真有那么高的价值吗? 2. 在做快速的技术Spike(技术调研),思考一下不写测试是不是能让我更快的试错?

我们要理解的是单元测试背后的核心价值,从而做出正确的取舍。我们要做的是编写出有效的单元测试,让它真正地为我们创造价值。

注释

Terminal:命令行终端

QA:专职测试人员

PM:项目经理

DEV:开发人员,DEVs表示复数

OOD:面向对象设计

FOP:函数时编程

TDD:测试驱动开发

CI:持续集成

本文转载自异步社区

软件开发 编程语言

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:敏捷开发能解决什么问题?
下一篇:全面认识 RUST -- 掌控未来的雷电
相关文章