显然,单元测试也并非免费的午餐。在立即测试模型中,单元测试是有开销的(在时间和金钱上面)。但是如果你查看右边曲线的方向,你会发现它花费了更多的开销——效率曲线急剧下降;而且生产率甚至会变成负值;这些生产率损耗可以很容易导致一个项目失败。
因此,如果你仍然认为在编写产品代码的时候,还是没有时间编写测试代码,那么请先考虑下面这些问题:
1. 对于所编写的代码,你在调试上面花了多少时间?
2. 对于以前你自认为正确的代码,而实际上这些代码却存在重大的bug,你花了多少时间在重新确认这些代码上面?
3. 对于一个别人报告的bug,你花了多少时间才找出导致这个bug 的源码位置?
对于那些没有使用单元测试的程序员而言,上面这些问题所耗费的时间的递增速度是很快的,而且随着项目的深入,递增速度会变得更快;而另一方面,适当的单元测试却可以很大程度地减少这些时间,从而能够为你腾出足够的时间来编写所有的单元测试——甚至可能还有剩余的空闲时间。
n 运行测试的时间太长了
合适的测试是不会让这种情况发生的。实际上,大多数测试的执行都是非常快的,因此你在几秒之内就可以运行成千上万个测试。但是有时某些测试会花费很长的时间,因此我们不能每次都运行这些测试,有时你就要暂时停止运行这些测试。
在这种情况下,需要把这些耗时的测试和其他测试分开。通常可以每天运行这种测试一次,或者几天一次;而对于运行很快的测试,则可以经常运行。