测试驱动开发

此博客文章停止维护，访问个人博客链接

www.wangqunxi.com

什么是测试驱动开发：

驱动测试开发：简单的说是先写测试用例，然后编写代码使其通过测试。 

为什么要驱动测试开发：

1. 开发人员的责任不仅是需求实现更重要的是质量保证。

只会开发功能的是码农，专家更注重代码质量。一个产品20%的成本是开发，80%都是维护成本。好的代码质量能大大的降低维护成本，为以后的功能扩展提供基础。

2. 及时的验证代码正确性：

任何问题发现的越早，那么修正他的成本越低。测试驱动开发让开发和测试的迭代周期变的更短，减少bug修复的成本。

3.回归测试

能保证在新功能开发中，对已有的功能做到及时自动的回归测试。时刻的运行单元测试，以保证及时的缺陷反馈，回归测试变得不再枯燥

4.代码重构

risk!!! if it ain't Broke, Don't fix it.(如果能用，就不要去碰他) -------开发者的魔咒
测试覆盖的程度决定着你对代码实施重大修改信心。不能演化迭代重构，只会让代码向死水一样腐败变臭。没有人能保证今天的代码甚至前期详细的设计能适应千变万化的未知。所以敏捷的的出现代替了传统的开发方法（最典型 waterfall）敏捷不是不要设计，敏捷是不要过度设计。敏捷不是需求驱动，敏捷是根据变化(需求，设计，代码等)进行灵活的调整，这不仅做加法，同时也要做减法。和传统开发相比，敏捷对开发者的要求更高（有点跑题）重构保证敏捷能更强的应对变化，而测试的覆盖则是保证重构成为行动，而不是口号。（推荐 Martin Fowler 的 Refactoring ）

5.设计分离

很多人编写完功能后才开始写单元测试，甚至为legacy code添加单元测试，结果发现举步维艰，成本甚至超过重写代码，最终他们选择了放弃(推荐本书《修改代码的艺术》)。如果到了这步你是否应该停下来好好想想，是否你的产品代码已经出了问题。 一个只能被产品代码调用，为其添加单元测试是如此困难，那只能说你的代码依赖性太大，被测代码不能很好地独立于客户代码。 然而测试驱动使你写代码之前就会考虑测试框架和客户代码的调用，提前思考核心业务代码的独立性。

6.新人的学习工具

任何产品随着时间的推移变得复杂，然而让一个新手在纷繁的业务逻辑和产品代码中去找已有的方法的使用必定会花大量的时间及成本。如果有了单元测试，那作为一个训练有素的开发者，完全可以忽略复杂的业务逻辑，而对一个已有类或则方法有更精准的了解， 这大大减少那又长又臭的文档维护。任何的文档如果不能做到及时的更新，那么随着时间他的描述会变得文不对题。你可以保证程序可以根据修去 去更新代码，你能保证他会好好的写你的文档吗，如果不能，那请你使用测试驱动开发吧。

测试驱动开发的步骤 （Kent Beck）

我觉得再也没有比Kent Beck在《Test Drive Development by Example》中所提到的5个步骤那样简洁明了：

1.快速编写一个测试用例
2.运行所有用例，测试用例未通过
3.做些小小的改动
4.运行所有的测试用例，并全部通过。
5.重构代码，去除重复。

所有测试驱动开发都是不停的迭代以上几个步骤。

测试驱动开发不是银弹

测试驱动开发并不能解决软件开发中所面临的全部问题，更不能替代其他的测试方法（集成测试，系统测试）

总结

以上观点只是在实践中的深有体会，并不是个人原创的观点。