三、程序员缘何拒绝编写单元测试?
我们已经知道了单元测试是多么重要的。为什么程序员仍然不编写单元测试呢?为什么程序员总是有理由拒绝编写单元测试呢?
1、 编写单元测试，增加了工作负担，会延缓项目进度?
这是笔者在多次讨论和调查中见到程序员拒绝编写单元测试的最多理由。“为了完成编码任务，没有足够的时间编写单元测试。编写单元测试会导致不能按时完成编码任务,推迟项目进度”。事实上真的是这样的吗?
软件有着其特殊的生命周期，软件开发也具有特殊性。
首先，我们需要提供给用户的至少是一个能运行的产品。绝对不能是一堆不能运行的和充满了“异味”的死代码。只有能够运行的，满足客户需求的代码才是真正有用的代码。这时，代码就变成产品了。
很多程序员只注重编写代码的完成时间，而乎略了调试代码，集成及修改和维护时间。
如果没有单元测试，开发活动会是这样情景。
以一个Web应用开发为例，流程大概如此：业务代码编写完成打包发布到服务器进行功能测试发现问题修改代码再打包……如此循环。
任何一个Web程序员对于这种开发情景都不会感到陌生。往往不断的打包、发布、功能测试的时间是代码编写的10倍以上。通过集成系统来发现程序的bug，我们往往很难一下子准确的定位bug产生的地方。应用服务器提供的错误信息对于我们来说是非常有限的。
如果为每一个类都编写单元测试并让每一个方法测试通过，又会是怎么样的开发情景呢?
编写测试代码编写业务代码运行测试方法修改代码让测试通过所有的类都通过测试打包发布到服务器进行功能测试发现bug修改测试代码修改业务代码测试通过再打包……如此循环。
从上面的过程显而易见，我们需要花费更多的编码时间。因为需要为每一个业务类编写测试代码。但是，它并不会导致我们总体需要花费更多的时间。我们只是可以非常轻松的在IDE环境中运行测试方法。
在代码尚未打包发布之前我们就已经确保了业务代码的正确性。当我们把所有通过测试的代码集成到应用服务器后，出现错误的机率要少得多。当集成测试后发现bug时,我们也总是先修改测试类。保证在集成之前所有的类都经过测试通过。这样，功能测试的时间就成数量级的减少,所以总的花费时间要比没有单元测试要少得多。
另外，如果没有单元测试，会经常出现一些低级的错误，如拼写错误、空指针异常等。就因为一个小小的拼写错误而需要重新打包、发布一次。如果有单元测试，就可以避免这些低级的错误。
如果没有单元测试，把代码集成到应用服务器后再发现错误时，我们往往更多的是凭借自己的经验来判断问题出在哪里。对于没有经验的程序员来说只能是撞运气了。这就像是瞎子走路一样，两眼一摸黑。如果每个类都有单元测试，就无需要这么痛苦了。
文章来源于领测软件测试网 https://www.ltesting.net/
