一、为了单元测试而写单元测试
最近笔者曾经做过一次“程序员在项目开发中编写单元测试的情况”的调查。
调查结果显示：
1. 几乎没有严格在项目中执行TDD（，TDD）。
2. 为大部份业务方法编写单元测试，并保证方法测试通过，占16.6%。
3. 偶尔编写单元测试，一般情况下不写单元测试，占58.3%。
4. 为了应付项目检查而写单元测试，但并不保证方法是否测试通过， 占8.3%。
5. 从来不编写单元测试，占16.6%。
虽然调查的结果有一定的片面性，但是占58.3%比例的确高的惊人，同时，从来不编写单元测试16.6%人层也基本反映国内程序员编写单元测试的状况，很少有程序员能够比较认真地去编写单元测试。那么，到底又是什么原因导致程序员不编写单元的测试的？根据笔者参与的多个讨论，主要有下面几种原因使程序员不编写单元测试：
1. 为了完成编码任务，没有足够的时间编写单元测试。编写单元测试会导致不能按时完成编码任务,推迟项目进度。
2. 单元测试的价值不高，完全是浪费时间。
3. 业务逻辑比较简单，不值得编写单元测试。
4. 不知道怎么编写单元测试。
5. 项目没有要求，所以不编写。
6. 在项目的前期还是尽量去编写单元测试，但是越到项目的后期就越失控。
测试常常是程序员十分厌倦的一个项目活动。测试能够为我们带来什么？了解这些非常的重要，测试不可能保证一个程序是完全正确的，但是测试却可以增强我们对程序完整的信心，测试可以让我们相信程序做了我们期望它做的事情。测试能够使我们尽早地发现程序的bug和不足。
一个bug被隐藏的时间越长，修复这个bug的代价就越大。在《快速软件开发》一书中已引用了大量的研究数据指出：最后才修改一个bug的代价是在bug产生时修改它的代价的10倍。
在这里，我们需要讨论的重点是单元测试。单元测试是一个方法层级上的测试，单元测试也是最细粒度的测试。用于测试一个类的每一个方法都已经满足了方法的功能要求。
在现代软件开发过程中，不管是XP还是RUP都是十分重视单元测试。已经把单元测试作为贯穿整个开发周期的一项重要的开发活动。特别是在现代软件开发过程中，有经常集成和渐近提交的方法论。由此，总结出了非常好的单元测试理论和实践。
二、在编写代码之前先编写单元测试,即测试先行
单元测试是代码的一部份，所有的代码必须有单元测试，并使测试通过（像在Spring这些优秀的开源项目中在这方面做出了非常好的例子）。
在修改代码之前先修改单元测试，并使它测试通过。
在编写代码之前先编写单元测试，会带来非常多的好处。
在编写代码之前先编写单元测试，并不是编写代码之前需要一次性为所有的类都事先编写单元测试，这需要有一个粒度的控制。最大的粒度应该控制在一个类级别上，最合适的粒度是控制在一个方法级别上。先为某一个方法编写测试代码，然后再为该方法编写实现代码，直到其测试通过后再为另一个方法编写测试代码，如此循环。单元测试在这里已经是一个契约规范了，它规范了方法应该做什么、实现什么。测试代码远远要比难以阅读和不会及时更新的需求文档更有价值得多。
测试先行，鼓励对需求的理解。如果没有理解需求，你是不可能写出测试代码的，当然你也不可能写出好的实现代码。
测试代码与其它文档相比会更有价值。当需求发生改变，实现代码也相应改变。而往往需求文档、设计文档得不到及时更新。测试代码相比那些过期的文档更具有价值。
测试先行可以编写出最大覆盖率的测试代码。如果在方法的实现代码编写完后再编写测试代码，这时开发人员总是编写一个正确路径的测试代码。它已经很难全面的去分析其它分支逻辑。
如果我们采用测试先行，那么就自动地完成了为所有的类都编写测试。为所有的类都编写测试会将为你带来非常多的好处。
我们可以很好地使用自动化测试来测试所有的类，特别是采用日构建的系统。可以让我们放心地为类或方法添加新的功能。我们可以很容易地修改测试代码并验证修改后的代码是有用的代码。可以让我们放心地对代码进行重构和进行设计优化。
重构和设计优化通常会关联到多个类及多个方法。如果我们为所有的类都编写了测试，我们就可以在重构代码后很轻松地进行测试我们的修改是否正确。
为所有的类编写测试，可以让我们很容易地修改bug。当接到一个bug报告后，我们总是先修改测试代码，然后修改实现代码，使测试成功。这样不会因为修改一个问题而造成新问题的产生。
良好的单元测试策略给我们增强了对程序的信心,减少了bug的产生及bug的潜伏期，降低修改bug的代价。
单元测试不会是项目开发周期的某一个生命周期，它贯穿于项目的整个生命周期，是一个非常重要的日常开发活动。
文章来源于领测软件测试网 https://www.ltesting.net/
