在听过了我们合情合理、热情洋溢的阐述之后，某些开发者会点头并且同意单元测试的必要性，但是也许仍然会告诉我们由于某些原因，不能编写单元测试。下面就是我们所听到的一些借口，当然其中也包含了我们的辩解。

　　● 编写单元测试太花时间了

　　对于开始做单元测试的初学者而言，这是出现次数最多的借口。当然，事实并不是这样的。首先，我们需要关注一下：在编写代码的时候，你在哪些地方花费了更多的时间。

　　大多数人都把测试看成某种只有在项目结束时才做的工作。但是，如果你到了那个时候才做单元测试的话，那么肯定会花费更多的时间。事实上，要想只在项目快要结束的时候才做单元测试，那简直是扯淡。

　　至少，我们可以这样来看待单元测试：假设你想用一台割草机来清除两英亩的草地。如果你在草很稀疏的时候就开始行动，那么工作将会很简单。但是如果你等到这块草地长上粗壮大树、缠绕灌木的时候才准备行动，那么工作将会变得非常困难。

图1.1   “立即测试”和“单一测试阶段”的比较

　　从长远看来，使用“立即测试模型”的代价比“延后测试模型”的代价要低。在你编写实现代码的时候，同时编写独立的测试代码，在项目最后就可以避免出现做了无用功的问题；代码中的bug 也会更少，因为你所依赖的都是已经通过测试的代码。于是，通过在开发过程中多花一点时间在编写单元测试上面，你就可以最小化在项目后期花费大量时间的风险。

　　从图 1.1 中你可以看到，“立即测试”和“延后测试”之间并没有权衡可言；而是直线效率和指数效率之间的对比，而且对于后者而言，复杂度会不断增加，并且在项目后期，很多工作需要从头再来。所有这些额外的工作都会影响你的工作效率，如图1.1 所示。

　　显然，单元测试也并非免费的午餐。在立即测试模型中，单元测试是有开销的（在时间和金钱上面）。但是如果你查看右边曲线的方向，你会发现它花费了更多的开销——效率曲线急剧下降；而且生产率甚至会变成负值；这些生产率损耗可以很容易导致一个项目失败。

　　因此，如果你仍然认为在编写产品代码的时候，还是没有时间编写测试代码，那么请先考虑下面这些问题：

　　1.  对于所编写的代码，你在调试上面花了多少时间？

　　2.  对于以前你自认为正确的代码，而实际上这些代码却存在重大的bug，你花了多少时间在重新确认这些代码上面？

　　3.  对于一个别人报告的bug，你花了多少时间才找出导致这个bug 的源码位置？

　　对于那些没有使用单元测试的程序员而言，上面这些问题所耗费的时间的递增速度是很快的，而且随着项目的深入，递增速度会变得更快；而另一方面，适当的单元测试却可以很大程度地减少这些时间，从而能够为你腾出足够的时间来编写所有的单元测试——甚至可能还有剩余的空闲时间。

　　● 运行测试的时间太长了

　　合适的测试是不会让这种情况发生的。实际上，大多数测试的执行都是非常快的，因此你在几秒之内就可以运行成千上万个测试。但是有时某些测试会花费很长的时间，因此我们不能每次都运行这些测试，有时你就要暂时停止运行这些测试。

　　在这种情况下，需要把这些耗时的测试和其他测试分开。通常可以每天运行这种测试一次，或者几天一次；而对于运行很快的测试，则可以经常运行。