测试驱动开发

什么是测试驱动

测试驱动的基本流程

• 定义应用程序的要求

• 熟悉应用程序的功能区域，确定要使用的单项功能项或功能要求

• 创建验证要求的测试列表

• 为功能或要求定义接口和类

• 编写测试代码

• 运行测试

• 根据测试生成产品代码

• 重新运行测试，根据测试修改产品代码，直到所有测试都通过

• 整理代码

• 重复上面的步骤

测试驱动的所采用的技术及工具

单元测试

• 可以明确地验证功能的正确性 ，提高开发速度和质量，加速了代码重构的过程

• 是一种设计行为

• 单元测试可以表现为文档化

• 具有回归性，可以随时随地的快速的运行测试来验证代码的准确性

重构

• 重构可以改进软件设计

• 重构使软件更加容易理解

• 重构可以帮助找出BUG

• 重构可以提高编程速度

模拟对象

GUI测试

• 让每个可视部件成为公共的实例变量

• 为每个可视组件提供存取的方法

• 让测试类成为内部类

• 使用反射来获取可视组件

测试驱动开发的优缺点

• 更清晰的代码——只写需要的代码

• 更好的设计

• 更出色的灵活性——鼓励程序员面向接口编程

• 更快速的反馈——不会到系统上线时才知道bug的存在

• 有助于设计简单清晰而易用的接口。因为总是先有测试代码，才编写实现代码，意味着总是从使用者的角度设计接口，只有简单易用的接口才方便测试时调用。

• 模块切分的足够小但是模块间保持极低的耦合度。为了方便测试，会尽力把重复的逻辑剥离出来，单独构建模块进行测试，并且尽量减少模块间的耦合，保持模 块相对独立和功能完备。如果模块过大，或者模块间强耦合，写测试用例与代码时就会困难重重，笨重复杂。因为总是先写测试代码，眼前的利益高于一切，将来的 实现代码必然要迁就目前测试的需要。于是， “不知不觉”设计出小粒度模块，且模块间耦合度低的实现。

• 肆无忌惮的重构。因为有测试用例和测试代码作担保，开发者能够从小心翼翼心惊胆战的重构中解脱出来，只要是更好的实现和设计，都愿意尝试。可以说，测试驱动开发鼓励代码的不断进化，即使测试已经全部通过，也可以通过大胆重构来改进设计与实现。尽管此时是否还需要再重构见仁见智，至少提供了一个可能。

• 测试代码是“活”的软件文档，它硬性规定了实现代码必须满足的需求，达不到就报错。传统的文本文档比之就苍白无力多了，“应该”，“必须”，这些字眼对程 序员有多少约束力？而且测试代码总是能与实现代码保持新鲜同步，传统文档写完后经常被上传服务器束之高阁，很少人问津，随着开发组内人员的变动，往往最后就湮没在服务器的故纸堆之中了。

• 定测试驱动开发不可能让人立即具有设计出优美解决方案的能力，或者说是优秀的分析与解决问题的能力。TDD不是Test Driven Design。它只是一个过程，也许可以帮助你发现并帮助你实现优美的解决方案，但是它不能变魔术一样，只要学会了就变出一个优美的设计出来，优秀的分析问题与解决问题的能力还是要靠不断地学习与借鉴他人成就才能得到提高。

• 测试驱动开发不能节省开发投入，也很少能够节省开发周期。测试开发所编写的大量测试代码都是要投入时间与精力的，测试代码与实现代码的比例基本在3:2，即使因为测试驱动开发能得到一个简洁的设计，也不能弥补测试代码的工作量。当然，测试代码可以一定程度保证高质量的实现代码，从而减少后期软件测试与修正缺陷的工作周期，并进一步在软件发布后减少代码修正维护的工作量。但至少在开发阶段，两相抵消，开发周期并不能有明显改善，如果是第一次采纳测试驱动开发，甚至会延长开发周期。

• 测试驱动开发不能杜绝所有的软件缺陷。尽管测试驱动开发通过测试约束，减少了程序员犯错和遗忘的可能，但是这只是把问题从实现代码部分地转移到了测试代 码。测试用例的完备与否，测试代码本身逻辑的正确与否都依赖于程序员，糟糕的测试用例设计和测试代码实现可能自顾不暇，也就失去了监督实现代码的能力。

模型驱动开发与测试驱动开发对比

• 模型驱动开发的版本圈复杂度是4，测试驱动开发的版本圈复杂度是2。但是测试时都需要同样的4个必要的测试用例。

• 两者在逻辑上是等价的。

• 模型驱动开发依赖于建模技术，测试驱动开发依赖于测试技术。

• 看起来模型驱动开发的版本更长，但是测试驱动开发的版本需要更多键盘输入工作（测试与调试），两者的程序规模没有本质区别。

• 测试驱动开发中的测试用例能帮助维护人员重新激发和隔离故障。