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

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

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

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


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

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

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

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

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

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

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

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

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

　　● 运行测试的时间太长了

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

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

　　● 测试代码并不是我的工作

　　这是一个很有趣的借口。请问，到底什么是你的工作呢？假设你的工作只是为了编写产品代码。如果对于那些没有把握的代码，你随便地扔给测试组，那么你实际上并没有完成你的工作。实际上，期望别人来清理我们的代码是很不好的做法；甚至在某种情况下，如果别人指出了一大摞有错误的代码，那么也意味着你的职位也到此为止了。

　　另一方面，如果测试员或者QA （Quality Assurance ）组发现很难在你的代码中挑出错误，那么你的名声将会一路高升??同时提升的还有你的职位。

　　● 我并不清楚代码的行为，所以也无从测试

　　如果你实在不清楚代码的行为，那么估计现在并不是编码的时候。或许你应该先建立一个原型，这样才有助于你认清需求。

　　如果你并不知道代码的行为，那么你又如何知道你编写的代码是正确的呢？

　　● 但是这些代码都能够编译通过

　　OK，还没有人把这个当成一个借口，至少没有大声地说出来。但是估计这很容易会成为一个借口，因为有些人总是认为：一个成功的编译是成功的标记；通过了编译，像通过了天堂的大门一样。

　　但是，编译器的默许只是对代码一种非常粗略的肯定。实际上，任何编译器和解释器都只能验证你的语法是否正确，并不能保证代码的行为也正确。例如，C# 的编译器可以很容易地检测到下面这行代码是错误的：

　　statuc void Main() { ……}


　　上面有个明显的打印错误，第2 个单词应该是static ，而不是statuc。这是很容易看出来的。