三、程序员缘何拒绝编写单元测试？
我们已经知道了单元测试是多么重要的。为什么程序员仍然不编写单元测试呢？为什么程序员总是有理由拒绝编写单元测试呢？
1、 编写单元测试，增加了工作负担，会延缓项目进度?
这是笔者在多次讨论和调查中见到程序员拒绝编写单元测试的最多理由。“为了完成编码任务，没有足够的时间编写单元测试。编写单元测试会导致不能按时完成编码任务,推迟项目进度”。事实上真的是这样的吗？
软件有着其特殊的生命周期，软件开发也具有特殊性。
首先，我们需要提供给用户的至少是一个能运行的产品。绝对不能是一堆不能运行的和充满了“异味”的死代码。只有能够运行的，满足客户需求的代码才是真正有用的代码。这时，代码就变成产品了。
很多程序员只注重编写代码的完成时间，而乎略了调试代码，集成及修改和维护时间。
如果没有单元测试，开发活动会是这样情景。
以一个Web应用开发为例，流程大概如此：业务代码编写完成打包发布到服务器进行功能测试发现问题修改代码再打包……如此循环。
任何一个Web程序员对于这种开发情景都不会感到陌生。往往不断的打包、发布、功能测试的时间是代码编写的10倍以上。通过集成系统来发现程序的bug，我们往往很难一下子准确的定位bug产生的地方。应用服务器提供的错误信息对于我们来说是非常有限的。
如果为每一个类都编写单元测试并让每一个方法测试通过，又会是怎么样的开发情景呢？
编写测试代码编写业务代码运行测试方法修改代码让测试通过所有的类都通过测试打包发布到服务器进行功能测试发现bug修改测试代码修改业务代码测试通过再打包……如此循环。
从上面的过程显而易见，我们需要花费更多的编码时间。因为需要为每一个业务类编写测试代码。但是，它并不会导致我们总体需要花费更多的时间。我们只是可以非常轻松的在IDE环境中运行测试方法。
在代码尚未打包发布之前我们就已经确保了业务代码的正确性。当我们把所有通过测试的代码集成到应用服务器后，出现错误的机率要少得多。当集成测试后发现bug时,我们也总是先修改测试类。保证在集成之前所有的类都经过测试通过。这样，功能测试的时间就成数量级的减少,所以总的花费时间要比没有单元测试要少得多。
另外，如果没有单元测试，会经常出现一些低级的错误，如拼写错误、空指针异常等。就因为一个小小的拼写错误而需要重新打包、发布一次。如果有单元测试，就可以避免这些低级的错误。
如果没有单元测试，把代码集成到应用服务器后再发现错误时，我们往往更多的是凭借自己的经验来判断问题出在哪里。对于没有经验的程序员来说只能是撞运气了。这就像是瞎子走路一样，两眼一摸黑。如果每个类都有单元测试，就无需要这么痛苦了。
写到这里，使得我回想起当年做网络系统。当时的局域网络都是采用环状网络，还没有现在的交换机来组星形网络。环状网络的传输网络采用同轴细缆线，网络中的所有节点都在一条主干线上，网络的两端都会加上一个电阻来形成一个环（如下图）。
环状网络的最大的缺点就是当任意一个节点有固障时，整个网络都不能连通。维护这种网络是非常麻烦的。通常采用得比较多的方法就是“切香肠”法。把最后一个电阻取下来，接到第二台电脑的网络节点的末端，检查两条线是否能连通。连通后再把电阻取下来到第三台电脑的网络节点的末端，连上第三台电脑。这样来依次检查整个网络的线路。
后来就发展了星形网络，也是现在局域网普遍采用的。有一台交换机，每一台电脑连接到交换机，任意一个节点网络故障不会影响到其它节点，检查起来就非常方便了。没有单元测试的代码就像是环状网络，而有测试的代码就像星形网络。
其次，有可能我们第一次编写的代码是没有问题的，但是到后来需求改变而修改了其中某些类的代码，把它发布到了应用服务器去测试，所要修改的内容已经测试通过了。但是因为某些类的代码的修改导致了其它类不能正常的工作。这种bug往往隐藏得非常深，因为只要不触动它，它就不会出现。可能会程序发布到生产环境之后才会被业务人员发现。如果每个类都有测试代码，我们在打包之前运行所有测试代码，就可以很容易的发现因为代码修改带来的连带性错误。
最后，在离bug产生越近，修正bug就越容易；在bug产生越远，修正bug的代价就越昂贵。假设我们去集成一个星期(甚至更长时间)前编写的代码，当发现问题时，我们已经忘掉了很多重要的实现细节,所以修改变得困难重重。
编写单元测试，并不会加重程序员的负担，反而提高了程序员对程序的信心，大大的减少了重复打包、发布、纠错误的时间。这些花费的时间远远要比编写单元测试花费的时候多几个数量级。编写单元测试，可以让你更容易和更放心地去修改代码，增加功能从而加快了项目的开发进度。
为什么我们总是要主观的去认为编写单元测试会延缓项目进度呢？与其痛苦的挣扎，还不如去尝试一下好的实践。
