五、为什么越在项目的后期，单元测试越难以进行下去？

　　在很多项目的初期，项目中的大部分程序员都能够自觉的去编写单元测试。随着项目的进展，任务的加重，离交付时间 越来越近，不能按时完成项目的风险越来越大，单元测试往往成为牺牲品了。项目经理因为进度的压力也不重视了，程序员也因为编码的压力和无人看官而不再为 代码编写单元测试了。

　　笔者所有亲历的项目都着像这么糟糕的情况发生。越是在项目的后期，能坚持编写单元测试的程序在整个项目组中不 会超过15%。为了追赶进度，绝大多数程序员都把没有经过任何测试的代码提交到版本服务器，项目经理也不再追问，照单全收。这样做的结果是在后期，集成 花费的时间越来越多，几个技术骨干人员只得日夜加班进行系统集成。好不容易集成完了之后，下发给测试人员测试时，bug的报告成数量级的增长。程序员日 以继夜的修改bug.还有非常多的bug被隐藏更深，一直潜伏到生产环境去。项目中，越来越多的人对项目失去信心，每一个人都在抱怨，数不清的bug，修 正了一个bug，更多的bug报告上来。

　　每天都在修改bug，但是每天又会报告上更多的bug。于是开始有人想逃离了，有人请假，也有人离职。当项目总算结束时，每一个的内心都清楚，项目太烂了，还有很多的错误还没被测试出来，赶快逃离这个项目组吧！一半的人病倒了，或对项目的维护失去了信心。

　　为什么会这样？有没有宣导测试的重要性呢？

　　在项目初期应该进行宣导单元测试的重要性。

　　有没有做过相关的培训工作？在项目启动时，需要进行一些相关的培训，教授团队成员基本的编写单元测试的技巧。

　　有没有做过相应的风险防范？越是工作资历越深的程序员，越会拒绝编写单元测试，他们总是有太多的理由来拒绝编写单元测试。这些顽固的老程序员 往往负责着核心的代码的编写。我们知道20-80定律吧。80%的错误是发生在20%的代码之中的，往往严重的错误发生在那些老鸟们的代码中。有没有 在事先做好风险防范，说服他们编写单元测试。

　　有没有做好测试相关的基础工作。有没有针对不同类型的程序编写测试基类，让编写测试变成一项非常简单的工作。有一些代码是依赖于特定的环境，如 EJB访问，JNDI访问，web应用程序依赖Servlet API等。测试这些程序是非常困难的。应该编写一些测试基类和测试stub，让这些程序可以脱离于特定环境像普通程序一样进行单元测试。让普通程序员轻 松的编写测试代码进行程序测试。

　　可以实行日构建和测试覆盖率检查，没有通过测试的代码绝不允许放到版本服务器。检查测试的覆盖率。
 
　　在现代软件开发过程中，测试不再作为一个独立的生命周期。单元测试成为与编写代码同步进行的开发活动。单元测试能够提高程序员对程序的信心，保证程序的质量，加快软件开发速度，使程序易于维护。不管测试先行还是测试后行，没有单元测试那是不行的。

　　弱者为失败找理由，强者为成功找方法！你单元测试了吗？