程序员为什么不写单元测试?[2] 单元测试工具
一个bug被隐藏的时间越长，修复这个bug的代价就越大。在《快速软件开发》一书中已引用了大量的研究数据指出：最后才修改一个bug的代价是在bug产生时修改它的代价的10倍。
在这里，我们需要讨论的重点是单元测试。单元测试是一个方法层级上的测试，单元测试也是最细粒度的测试。用于测试一个类的每一个方法都已经满足了方法的功能要求。
在现代软件开发过程中，不管是XP还是RUP都是十分重视单元测试。已经把单元测试作为贯穿整个开发周期的一项重要的开发活动。特别是在现代软件开发过程中，有经常集成和渐近提交的方法论。由此，总结出了非常好的单元测试理论和实践。
二、在编写代码之前先编写单元测试,即测试先行
单元测试是代码的一部份，所有的代码必须有单元测试，并使测试通过(像在Spring这些优秀的开源项目中在这方面做出了非常好的例子)。
在修改代码之前先修改单元测试，并使它测试通过。
在编写代码之前先编写单元测试，会带来非常多的好处。
在编写代码之前先编写单元测试，并不是编写代码之前需要一次性为所有的类都事先编写单元测试，这需要有一个粒度的控制。最大的粒度应该控制在一个类级别上，最合适的粒度是控制在一个方法级别上。先为某一个方法编写测试代码，然后再为该方法编写实现代码，直到其测试通过后再为另一个方法编写测试代码，如此循环。单元测试在这里已经是一个契约规范了，它规范了方法应该做什么、实现什么。测试代码远远要比难以阅读和不会及时更新的需求文档更有价值得多。
测试先行，鼓励对需求的理解。如果没有理解需求，你是不可能写出测试代码的，当然你也不可能写出好的实现代码。软件测试
测试代码与其它文档相比会更有价值。当需求发生改变，实现代码也相应改变。而往往需求文档、设计文档得不到及时更新。测试代码相比那些过期的文档更具有价值。
测试先行可以编写出最大覆盖率的测试代码。如果在方法的实现代码编写完后再编写测试代码，这时开发人员总是编写一个正确路径的测试代码。它已经很难全面的去分析其它分支逻辑。
如果我们采用测试先行，那么就自动地完成了为所有的类都编写测试。为所有的类都编写测试会将为你带来非常多的好处。
我们可以很好地使用自动化测试来测试所有的类，特别是采用日构建的系统。可以让我们放心地为类或方法添加新的功能。我们可以很容易地修改测试代码并验证修改后的代码是有用的代码。可以让我们放心地对代码进行重构和进行设计优化。
重构和设计优化通常会关联到多个类及多个方法。如果我们为所有的类都编写了测试，我们就可以在重构代码后很轻松地进行测试我们的修改是否正确。
为所有的类编写测试，可以让我们很容易地修改bug。当接到一个bug报告后，我们总是先修改测试代码，然后修改实现代码，使测试成功。这样不会因为修改一个问题而造成新问题的产生。
良好的单元测试策略给我们增强了对程序的信心,减少了bug的产生及bug的潜伏期，降低修改bug的代价。
单元测试不会是项目开发周期的某一个生命周期，它贯穿于项目的整个生命周期，是一个非常重要的日常开发活动。
文章来源于领测软件测试网 https://www.ltesting.net/