4、项目没有要求，所以不编写单元测试

        的确，在很多项目中团队并没有要求我们为每一个类编写单元测试，反而会要求我们编写很多复杂的文档。作为程序员我们需要明白：程序员是编写单元测试的最大受益者。

        这不是项目经理的事，也不是QA的事，而是程序员自身的事，因为单元测试是程序代码的一部份。单元测试是最好的，最有价值的文档，它应该与代码一起交付给客户。

        单元测试代码不是官僚、死板的文档。它是生动的，是程序员最有用的文档。单元测试能够提高程序员对程序的信心，能够使用养成良好的设计原则：“针对接口编程，而不是具体类”。因为要进行单元测试，所以我们需要让类独立于其依赖对象(使用Mock或stub)进行测试。这就迫使我们养成了良好的编程习惯。

        单元测试是改进我们设计的保证。做为一个优秀的程序员，是会经常优化代码和设计，所以经常的进行重构。一个优秀的程序员绝对不能容忍“异味”代码，而单元测试就是我们进行重构的信心保证。

        单元测试是一个日常开发活动，它贯穿于项目的整个生命周期。做一个负责任的程序员总是为自己的代码的质量负责的。是否经常改进你的设计，是否让别人很轻松的使用和修改你的代码。

        为所有类编写单元测试应该是一个程序员应具有的素质。项目有没有要求，不应当成为不编写单元测试的理由。

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

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

        笔者所有亲历的项目都或多或少地有这么糟糕的情况发生。越是在项目的后期，能坚持编写单元测试的程序就在整个项目组中不会超过15%。

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

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

        为什么会这样？有没有宣导测试的重要性呢？在项目初期应该进行宣导单元测试的重要性。

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

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

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

        可以实行日构建和测试覆盖率检查，没有通过测试的代码绝不允许放到版本服务器。检查测试的覆盖率。

        在现代软件开发过程中，测试不再作为一个独立的生命周期。单元测试成为与编写代码同步进行的开发活动。单元测试能够提高程序员对程序的信心，保证程序的质量，加快软件开发速度，使程序易于维护。不管测试先行还是测试后行，没有单元测试那是绝对不行的。

        弱者其找理由，强者找方法！今天你单元测试了吗？