笔记曾经做过一次“程序员在项目开发中编写单元测试的情况”的调查。调查结果：

　　1.严格的在项目中执行TDD 几乎没有

　　2.为大部份业务方法编写单元测试，并保证方法测试通过。 占16.6%

　　3.偶尔编写单元测试，一般情况下不写。 占58.3%

　　4.为了应付项目检查而写单元测试，但并不保证方法是否测试通过。 占8.3%

　　5.从来不编写单元测试。占16.6%

　　因为调查具有一定的局限性或片面性，调查结果并不十分精确。也基本能够反映国内程序员编写单元测试的状况。很少有程序员能够比较认真的去编写单元测试。那么到底又是什么原因呢？根据笔者参与的多个讨论，主要有下面几种原因使程序员不编写单元测试。

　　1.为了完成编码任务，没有足够的时间编写单元测试。编写单元测试会导致不 能按时完成编码任务，推迟项目进度。

　　2.单元测试的价值不高，完全是浪费时间。

　　3.业务逻辑比较简单，不值得编写单元测试。

　　4.不知道怎么编写单元测试。

　　5.项目没有要求，所以不编写

　　6.在项目的前期还是尽量去编写单元测试，但是越到项目的后期，越失控。
 
　　测试常常是程序员十分厌倦的一个项目活动。测试能够为我们带来什么？了解这些非常的重要。测试不可能保证一个程序是完全正确的，但是测试却可以增强我们对程序的信心，测试可以让我们相信程序做了我们期望它做的事情。测试能够使我们尽量早的发现程序的bug。

　　一个bug被隐藏的时间的越长，修复这个bug的代价越大。在《快速软件开发》一书中已引用了大量的研究数据。指出：后才修改一个bug的代价是在bug产生时修改它的代价的10倍。

　　在这里，我们需要讨论的重点是单元测试。单元测试是一个方法层级上的测试，单元测试也是细粒度的测试。用于测试一个类的每一个方法都已经满足了方法的功能要求。

　　在现代软件开发过程中，不管是xp还是rup都是十分重视单元测试。已经把单元测试作为贯穿整个开发周期的一项重要的开发活动。特别是在现代软件开发过程中，有经常集成和渐近提交的方法论。总结出了非常好的单元测试理论和实践:

　　在编写代码之前先编写单元测试，即测试先行

　　单元测试是代码的一部份，所有的代码必须有单元测试，并使测试通过。（像在Spring这些的开源项目中在这方面做出了非常好的例子）

　　在修改代码之前先修改单元测试，并使它测试通过。
 
　　在编写代码之前先编写单元测试，会带来非常多的好处：

　　在编写代码之前先编写单元测试，并不是编写代码之前需要一次性为所有的类都事先编写单元测试。这需要有一个粒度 的把握。大的粒度应该控制在一个类级别上，合适的粒度是控制在一个方法级别上。先为某一个方法编写测试代码，然后再为该方法编写实现代码，直到其测试 通过后再为另一个方法编写测试代码，如此循环。单元测试在这里已经是一个契约规范了，它规范了方法应该做什么，实现什么。测试代码远远要比难以阅读和不会 及时更新的需求文档更有价值。

　　测试先行，鼓励对需求的理解。如果没有理解需求，你是不可能写出测试代码的，当然你也不可能写出好的实现代码。

　　测试代码与其它文档相比会更有价值。当需求发生改变，实现代码也相应改变。而往往需求文档，设计文档得不到及时更新。测试代码相比那些过期的文档更具有价值。

　　测试先行可以编写出大覆盖率的测试代码。如果在方法的实现代码编写完后再编写测试代码，这时开发人员总是编写一个正确路径的测试代码。它已经很难全面的去分析其它分支逻辑。

　　如果我们采用测试先行，那么自动的完成了为所有的类都编写测试这个实践原则。为所有的类都编写测试会将为你带来非常多的好处:

　　我们可以很好的使用自动化测试来测试所有的类，特别是采用日构建的系统。

　　可以让我们放心的为类或方法添加新的功能。我们可以很容易的修改测试代码并验证修改后的代码是有用的代码。

　　可以让我们放心的对代码进行重构和进行设计优化。重构和设计优化通常会关联到多个类及多个方法。如果我们为所有的类都编写了测试，我们可以在重构代码后很轻松的进行测试我们的修改是否正确。

　　为所有的类编写测试，可以让我们很容易的修改bug。当接到一个bug报告后，我们总是先修改测试代码，然后修改实现代码，使测试成功。这样不会因为修改一个问题而造成新问题的产生。