在向开发人员介绍单元测试或TDD等工程实践时,往往可以听到这样的疑问。比如:
自己写的程序,自己无法从另一个角度测出问题。写bug的时间都不够了,哪有时间来写测试?开发来写测试了,测试干什么?除了核心的代码,没有什么值得测试的。……
本篇想要通过探讨这些问题背后的困难,来说明程序员怎样通过编写自测代码更有效率的进行开发。
一个例子
首先我们看一个例子。全项目唯一的测试
不止一次,我在各种项目中看到这样的测试,往往这也是整个工程中唯一一个测试。
可以看出,开发者认为编写是有必要的。所以按照“标准”的做法建立了测试目录,引入JUnit依赖。并且利用它在开发的初期来验证某些技术疑问,一般是某些当时还不熟悉的第三方库,或者数据库、中间件等外部依赖。
简单而言:“写测试是应该,但我们的代码没什么好测的”
测试,不仅仅关于未知
说起测试,往往与未知相关联。我们通过试验、调试、检测来获取获取反馈,不断调整。
以上图为例,一般想到的测试,都集中在“已知的未知”这个象限。正如前面的示例代码,使用不熟悉的库带来未知。程序员通过在测试中调用和观察结果来消除未知。
然而,对于自动化测试来说,其实关注点在于已知。
“都已知了,还测试什么呀?”,也许你会有这样的疑问。
火柴问题
火柴,这种行将消失的物品。也许现在的小朋友只是在《卖火柴的小女孩》中才得知它的存在。在我小时候,还是时常用到的。那时,也许是工艺问题,或者存储条件有限,往往一盒火柴好多根都不能点着。
记的那时听到的笑话:
小明的妈妈让他去买盒火柴,不一会功夫买回来了。妈妈问:“你试过没有,能点着吗?”
“试过啦”,小明很骄傲的说,“每一根我都试了一遍。”
我把这种问题称为“火柴问题”,往往传统的质量控制面临的都是这类问题,有如下限制:
成本,显然现实中不会有人把所有的火柴拿来测试。不过问题的本质并没有变,在花费的成本和获得安全保证的完全性之间取一个平衡。
事后,造出火柴后才有能否点着的问题&#x