不觉间，从事软件测试驱动开发（Test Driven Development）半年有余，自从看了Robert Martin的《敏捷软件开发：原则、模式与实践》， 就忍不住想实践一下，亲身体会书中描述的美妙景象。恰逢项目中一个全新功能交由我负责，开发周期也不是十分急迫，就拿这个新功能当回小白鼠，遵循书中的实践方法开始进行软件测试驱动开发。
随着开发的不断深入，软件测试驱动开发的实践渐入佳境，对其认识也从开始时的顶礼膜拜逐渐回归理性，在为其优长欢欣鼓舞的同时，更理解了其不足或者说是不具备的能力。
软件测试驱动开发意味着不再是从需求分析与概要设计/详细设计后直接进入到实现代码的编写，而是转而根据需求分析和概要设计进行软件测试用例的设计与软件测试代码的编写，通过软件测试代码硬性规定了实现代码所必须满足的功能需求、容错能力。编写实现代码的唯一目的就是使所有测试用例成功运行，任何测试用例的失败都意味着实现代码存在功能缺陷或者逻辑错误。之后就是不断重复--修改或增加代码再运行所有测试用例检查结果--的迭代过程。
看上去很简单的一个过程，却与传统的开发格格不入，惯性的力量导致开始时很难从传统过程的思维方式中摆脱出来。在做完需求分析与概要设计，开始设计测试用例与编写测试代码时手足无措，只能摸着石头过河，试着去做去写，然后通过测试驱动开发的迭代过程去观察，去体会，去修改，去适应，然后再重复迭代过程。就这样，渐渐理解了测试驱动开发这种“进化->测试->反馈->再进化->…”迭代循环的自然与强大，从测试中得到的反馈不仅说明实现代码的完备和健全与否，也给人不断进步之感，似乎总是在脚踏实地的前进着。因为在迈开每一步之前，都知道已有的工作经受了测试的检验，就具有相应的信心。即使发现有更好更优秀的设计实现，也可以放心大胆的彻底重构，因为有软件测试用例和软件测试代码作监督作守候。
此外，测试驱动开发也改变了原先开发的视角，不再是直接编写实现代码，而是转而从旁观者和使用者的角度设计软件测试用例和软件测试代码，总是能够发现很多原先忽略的因素和条件。
本文转载自51Testing软件测试网（查看全文）：
http://www.51testing.com/html/86/n-141686.html