分类：
2008-10-15 16:45:42
赛门铁克误杀门事件在一片争议声中落下了帷幕，但是它身后隐蔽的问题还远未结束，诺顿误杀彰显价值的回归，同时也向广大的程序员们敲响了警钟，不做单元的程序员在未来发展中绝对无路可走，以下是笔者的一些分析。
一、为了单元测试而写单元测试
最近笔者曾经做过一次“程序员在项目开发中编写单元测试的情况”的调查。
调查结果显示：
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这些优秀的开源项目中在这方面做出了非常好的例子）。
[1]
