Test Driven Development 测试驱动开发

Test Driven Development 

红绿蓝测试

测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。

TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。

TDD的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。

 

 

独立测试，测试列表（csv），测试驱动，先写断言，可测试性，及时重构，小步前进 

 

优缺点

优点：在任意一个开发节点都可以拿出一个可以使用，含少量bug并具一定功能和能够发布的产品。

缺点：增加代码量。测试代码是系统代码的两倍或更多，但是同时节省了调试程序及挑错时间。

TDD = TFD + Refactoring

(TFD -- Test First Development) 

其理念主要是确保两件事：

• 确保所有的需求都能被照顾到。
• 在代码不断增加和重构的过程中，可以检查所有的功能是否正确。

TDD 的基本过程可以拆解为以下 6 个步骤：

1） 分析需求，把需求拆分为具体的任务。

2） 从任务列表中取出一个任务，并对其编写测试用例。

3） 由于没有实际的功能代码，测试代码不大可能会通过（红）。

4） 编写对应的功能代码，尽快让测试代码通过（绿）。

5） 对代码进行重构，并保证测试通过（重构）。

6） 重复以上步骤。

可以用下图来表示上述过程。

 

 

TDD 流程比较关键的一环在于如何写出有效的测试代码，这里有 4 个原则可以参考：

1）测试过程应该尽量模拟正常使用的过程。

2）应该尽量做到分支覆盖。

3）测试数据应该尽量包括真实数据，以及边界数据。

4）测试语句和测试数据应该尽量简单，容易理解。

注意，这 4 个原则不仅适用于 TDD，同样适用于任何流程下的单元测试。

 

TDD原则 

独立测试：不同代码的测试应该相互独立，一个类对应一个测试类（对于C代码或C++全局函数，则一个文件对应一个测试文件），一个函数对应一个测试函数。用例也应各自独立，每个用例不能使用其他用例的结果数据，结果也不能依赖于用例执行顺序。 一个角色：开发过程包含多种工作，如：编写测试代码、编写产品代码、代码重构等。做不同的工作时，应专注于当前的角色，不要过多考虑其他方面的细节。

测试列表：代码的功能点可能很多，并且需求可能是陆续出现的，任何阶段想添加功能时，应把相关功能点加到测试列表中，然后才能继续手头工作，避免疏漏。

测试驱动：即利用测试来驱动开发，是TDD的核心。要实现某个功能，要编写某个类或某个函数，应首先编写测试代码，明确这个类、这个函数如何使用，如何测试，然后在对其进行设计、编码。

先写断言：编写测试代码时，应该首先编写判断代码功能的断言语句，然后编写必要的辅助语句。

可测试性：产品代码设计、开发时的应尽可能提高可测试性。每个代码单元的功能应该比较单纯，“各家自扫门前雪”，每个类、每个函数应该只做它该做的事，不要弄成大杂烩。尤其是增加新功能时，不要为了图一时之便，随便在原有代码中添加功能，对于C++编程，应多考虑使用子类、继承、重载等OO方法。

及时重构：对结构不合理，重复等“味道”不好的代码，在测试通过后，应及时进行重构。

小步前进：软件开发是复杂性非常高的工作，小步前进是降低复杂性的好办法。