赛门铁克误杀门事件在一片争议声中落下了帷幕，但是它身后隐蔽的问题还远未结束，诺顿误杀彰显测试价值的回归，同时也向广大的程序员们敲响了警钟，不做单元测试的程序员在未来发展中绝对无路可走，以下是笔者的一些分析。
一、为了单元测试而写单元测试
最近笔者曾经做过一次“程序员在项目开发中编写单元测试的情况”的调查。
调查结果显示：
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都是十分重视单元测试。已经把单元测试作为贯穿整个开发周期的一项重要的开发活动。特别是在现代软件开发过程中，有经常集成和渐近提交的方法论。由此，总结出了非常好的单元测试理论和实践。
相关专题
- 单元测试的小技巧介绍和举例 (0次浏览)
- 单元测试的基本方法 (0次浏览)
- 从生物学的角度对中间件和构件的思考 (0次浏览)
- 从EAI到SOA (0次浏览)
- 初为项目经理注意事项 (0次浏览)
- 程序员为什么不写单元测试？ (0次浏览)
- 程序员是一只捕鱼的鸟 (0次浏览)
- 成功项目管理的20个秘密 (0次浏览)
- 成功实施SOA的10大要素 (0次浏览)
- 成功的项目管理入门 (0次浏览)
