5 可是我还是不想测试

        看了上面的这些介绍后，也许你能理解单元测试的必要性，也许你还在犹豫，而且还有不少的理由

        编写单元测试很费时间

        我听很多人这么说过。我们来看一个容易理解的例子。

        小时候经常跟我妈一起去地里除草，我妈经常说，要在草很小的时候把它锄掉，如果不管它，一场雨之后，草就会长得很多、很密集，这时就难除多了。

        程序中的bug是不是像地里的杂草呢？

        下面的两幅图表明了“立即测试”和“单一测试阶段”的比较。

        长远来看，使用“立即测试”模型的的生产力将大大高于“单一测试”模型。在开发过程中多花一点时间在编写单元测试上面，就可以降低在项目后期花费大量时间的风险。

        单元测试并非免费的午餐。在“立即测试”模型的开始阶段，要花费一些时间编写单元测试，但随着时间的推进，“单一测试”模型就会花费更多时间——生产力急剧下降，甚至会成为负值。

        简单的说，“出来混，总是要还的”。

        如果你还是认为没有时间编写测试代码，那么考虑下面这些问题：

    1、 对于编写的代码，调试花了多长时间？

    2、 对于那些你认为正确，实际上却存在bug的代码，确认它们花了多长时间？

    3、 对于一个别人发现的bug，你定位它花了多长时间？

        前面说过，单元测试正是能够减少调试、定位时间的一种方法，所以舍弃单元测试实在是得不偿失啊。

        运行测试的时间太长了

        好的测试不该这样。大多数测试的执行都是很快的，可以在几秒钟内运行成千上万的测试。但是某些测试会花费很长的时间，因此我们不能每次都运行这些测试。

        可以将这些很耗时的测试与其它测试分开，通常可以每天运行这种测试一次，或几天一次；而其它运行很快的测试，则可以经常运行。

        测试代码不是我的工作

        忘了吗？单元测试是由程序员编写并执行的，它能使程序员的代码更加完美。你的工作不就是编写更好的代码吗？

        那些可恶的遗留代码没法测试

        很多人说，他们不能做单元测试，因为那些既有的代码错综复杂、难以理解，没法进行独立的测试。要测试一小段代码，也要牵扯到整个系统，做出任何修改都有风险。

        但这不是单元测试的错，错在那些设计很差的遗留代码。你需要去重构，整理那些遗留代码。注意，这么做可不全是为了测试之需，单元测试的真正威力在于对设计的回馈，如果使用得当，我们会得到更好的面向对象的设计。

        由于遗留代码的羁绊，我们将会在那种谨慎、忧虑的状态下编码，其效率可想而知，这不利于项目，不利于程序员，最终也不利于商业利益。引入单元测试将帮助解除这些羁绊。

        我不是很确定代码的行为

        如果这样，说明还不是编码的时候。这时原型可能会有帮助。

        我拿薪水，是因为我在编码，而不是编写测试

        如果你这么说，你整天调试的时候，就不该付你薪水。大概说来，你拿到薪水是因为你写出了可以工作的代码，而单元测试就是一个不错的工具来帮你达到此目的。它的作用就像一个编辑器、IDE或编译器。

        单元测试会让测试人员和QA失业，我会为此感到内疚

        你实在多虑了。我们说的仅仅是单元测试。它是给程序员用的。还有很多其它事情等着测试人员和QA去做呢，比如功能测试、接受性测试、性能和环境测试、验证等等。

        公司不允许我在真实环境下运行单元测试

        靠！我们现在说的是开发人员进行的单元测试啊。虽然你可能会在其它环境（比如真实的生产系统）运行相同的测试，但它们已不属于单元测试。单元测试应当在你自己的机器伤执行，使用自己的数据库或者使用Mock对象。

        我们可是已经单元测试了

        单元测试需要很大的热情去维系。如果团队缺乏热情，就有可能没有正确地进行单元测试。看看你的团队是否有如下的警告信号：

        所做的单元测试其实是集成测试，需要很多代码去组装和测试代码，需要很长的时间去执行，并且需要访问诸如数据库和网络服务这样的资源。

        单元测试太少，只测试了一条（代码）路径，没有测试例外的情况（没有磁盘空间等），或者并没有表达出代码的意图。

        单元测试无人维护：如果测试失败了，就每人去管了（甚至删掉），或者不去添加新的单元测试，即使遭遇的bug已经表明单元测试的覆盖率不足了。