不写单元测试的那些理由

—— 不写单元测试,总有一个借口适合你

做为一个写代码的程序员. 编写单元测试是我们基本的,必备的能力之一. 单元测试是保障我们编写的代码质量的最基础“质量把关”.

编写单元测试是一个程序员自我保障自己代码质量的最重要的一个方式, 如果一个写代码的人,自己对自己的代码都没有想办法去保障, 而只是依赖外部测试团队来保障, 可想而知, 这样的程序员是不专业的.

想像一下这句话: “我不关心我写的代码质量如何, 因为有外部测试团队会测试我写的代码的功能质量”

这样的程序员是不专业的,而不专业的程序员,是软件之所以不断延时,BUG不断, 无法维护等恶劣情况的一个重要的原因.

导致程序员自己都不愿意写单元测试究竟有哪些理由? 我就来分析下这些常见的理由.

不写单元测试的原因

没时间

我相信没有比这个借口更充分的借口了. 几乎大多数程序员不写单元测试的一个重要理由就是: 这个功能时间很紧, 没有时间去编写单元测试了.

因为大家普遍相信一个简单的公式:

时间 (写代码 + 单元测试代码) > 时间 (写代码)

不仅程序员自己相信这个公式, 当程序员把这个原因告诉其它诸如项目经理,产品或管理人员, 这些人也能被这个理由轻易说服.

时间不够,先不写吧,以后有时间再补. 当时,我们都知道, 以后是没有的,也是不存在的虚幻的概念.

虽然这是个错误的公式,但它确实普遍得到认可,成为不写单元测试的绝佳借口.

不会写

好吧, 很少有程序员会这么直白的和别人说, 我没有学习过如何写单元测试, 我不会写.

这等于在说自己无能一样,很少有人这么直白的承认.

但实际上, 那些很少或从来没有写过单元测试的程序员, 让它基于给自己写的代码加上单元测试, 如果不去学习, 这可能还不一定会.

写单元测试,并不是简单的事, 你得选择一个合适的单元测试框架去辅助你, 再对代码中的一些第三方依赖或服务考虑MOCK或虚拟实现等, 还要覆盖正常路径以及异常路径. 还要学会如何正确的断言.

这与学习任何一门新语言或使用一个新框架一样, 是需要花时间学习的, 并且需要时间的积累,你才有可能能写出好的单元测试.

没法写

没有写过单元测试的程序员可能不明白,并不是任何代码都能轻易的为它编写一个单元测试.

很多人写的代码不够简洁, 属于那种“大泥团代码”. 可能逻辑错综复杂, 依赖混乱, 拥有各式各样的“上帝类”或“上帝方法”, 也就是垃圾代码.

为垃圾代码写单元测试是件困难的事. 因为你会发现无从下手. 所谓单元测试,英文是Unit Test, Unit是一个小块, 也就是为一个小的代码块编写测试代码来证明它是正确的. 但是很多代码的现状,可能没法做到只运行一个小的代码块.

很多代码的现状是, 想要运行一个小的代码块,你得把整个系统或服务运行起来, 甚至是各种无关的依赖或服务. 然后没法测试这一小块代码, 你得完整的从上到下把整个链路运行起来,才能在运行中包括这一小块代码.

想要写单元测试,简洁的代码是基础. 垃圾代码是没法写单元测试, 那确实是真的浪费时间.

缺少约束

写代码,并不是单纯的写代码. 编写代码只是一种方式,一种工具,最终肯定是为了服务其它目的, 比如开发出一个什么业务服务,为客户提供服务,为公司带来价值等.

任何项目或软件,一定有两种价值, 一种是业务价值,一种是技术价值. 而单元测试是隶属于技术价值, 相对业务价值, 技术价值易于被忽略.

在编程的现实中, 除非软件开发团队的技术氛围深厚或技术人员能掌握较大话语权, 才可能会对软件的技术价值比较重视. 但这并不是主流, 我们得承认,大多数现实的现状是技术人员缺少足够的话语权, 而管理人员或产品更关注软件的功能价值.

因此, 这个迭代开发哪些功能, 花多少时间完成, 什么时候能上线这些成为量化的指标,是管理人员管理与关注的重点. 而单元测试这种事情, 管理并不会重视技术上那些不易察觉的质量.

这种难以量化, 会造成一个如果不是程序员自己主动有要求, 大多数情况下团队或管理人员不会对它有任何要求.

没有外部约束, 写代码的自己又不主动, 自然单元测试就被凉在一边了.

很多程序员的认知完全是错误的. 比如单元测试会增加编码时间等.

事实上, 根据我的体验, 单元测试的价值非常多, 包括但不限于:

当然,很多人可能不相信这些价值. 但以我的体验来说, 这都是实实在在的价值.

后续我有空再详细说下.

我想建议的是,每一个热爱编码,追求专业的程序员,都应该有主动编写单元测试的意识.