测试驱动开发

最新推荐文章于 2019-08-10 22:28:33 发布

wuhuan_001

最新推荐文章于 2019-08-10 22:28:33 发布

阅读量731

点赞数

分类专栏：杂谈

杂谈专栏收录该内容

39 篇文章 0 订阅

订阅专栏

测试驱动开发（Test-Driven Development，TDD）是通过测试定义所要开发的功能的接口，然后实现功能的开发过程。

(TDD)，是Extreme Programming (XP)--极限编程的一个重要组成部分。在上面的图中，列出的的是XP的12个团队实践。Test-Driven Development是其中之一。pment

在上面的图中，列出的的是XP的12个团队实践。Test-Driven Development是其中之一。

Kent Beck 的著作TDD(Test Driven Development) 中详细讲述了测试驱动开发。

当你使用TDD的时候一定要说明是测试驱动开发还是测试驱动设计。这两者是有区别的。测试驱动开发，是通过测试定义所要开发的功能的接口，然后实现功能的开发过程。对于测试驱动设计，在XP中似乎已经消失了，而是被测试驱动开发所取代。另外在XP中有用于描述设计的，SimpleDesign ，Design Improvement.

一、测试驱动开发的基本过程

      1）明确当前要完成的功能。可以记录成一个 TODO 列表。
      2）快速完成针对此功能的测试用例编写。
      3）测试代码编译不通过。
      4）编写对应的功能代码。
      5）测试通过。
      6）对代码进行重构，并保证测试通过。
      7）循环完成所有功能的开发。

二、测试驱动开发的原则

1）测试隔离。不同代码的测试应该相互隔离。对一块代码的测试只考虑此代码的测试，不要考虑其实现细节（比如它使用了其他类的边界条件）。

2）一顶帽子。开发人员开发过程中要做不同的工作，比如：编写测试代码、开发功能代码、对代码重构等。做不同的事，承担不同的角色。开发人员完成对应的工作时应该保持注意力集中在当前工作上，而不要过多的考虑其他方面的细节，保证头上只有一顶帽子。避免考虑无关细节过多，无谓地增加复杂度。

3）测试列表。需要测试的功能点很多。应该在任何阶段想添加功能需求问题时，把相关功能点加到测试列表中，然后继续手头工作。然后不断的完成对应的测试用例、功能代码、重构。一是避免疏漏，也避免干扰当前进行的工作。

4）测试驱动。这个比较核心。完成某个功能，某个类，首先编写测试代码，考虑其如何使用、如何测试。然后在对其进行设计、编码。

5）先写断言。测试代码编写时，应该首先编写对功能代码的判断用的断言语句，然后编写相应的辅助语句。

6）可测试性。功能代码设计、开发时应该具有较强的可测试性。其实遵循比较好的设计原则的代码都具备较好的测试性。比如比较高的内聚性，尽量依赖于接口等。

7）及时重构。无论是功能代码还是测试代码，对结构不合理，重复的代码等情况，在测试通过后，及时进行重构。

三、测试驱动开发的测试范围

按大师 Kent Benk 的话，对那些你认为应该测试的代码进行测试，测试驱动开发强调测试并不应该是负担，而应该是帮助我们减轻工作量的方法。

四、TDD的优点

『充满吸引力的优点』

      完工时完工。表明我可以很清楚的看到自己的这段工作已经结束了，而传统的方式很难知道什么时候编码工作结束了。
      全面正确的认识代码和利用代码，而传统的方式没有这个机会。
      为利用你成果的人提供Sample，无论它是要利用你的源代码，还是直接重用你提供的组件。
      开发小组间降低了交流成本，提高了相互信赖程度。
      避免了过渡设计。
      系统可以与详尽的测试集一起发布，从而对程序的将来版本的修改和扩展提供方便。
      TDD给了我们自信，让我们今天的问题今天解决，明天的问题明天解决，今天不能解决明天的问题，因为明天的问题还没有出现(没有TestCase)，除非有TestCase否则我决不写任何代码；明天也不必担心今天的问题，只要我亮了绿灯。

『不显而易见的优点』

      逃避了设计角色。对于一个敏捷的开发小组，每个人都在做设计。
      大部分时间代码处在高质量状态，100％的时间里成果是可见的。
      由于可以保证编写测试和编写代码的是相同的程序员，降低了理解代码所花费的成本。
      为减少文档和代码之间存在的细微的差别和由这种差别所引入的Bug作出杰出贡献。
      在预先设计和紧急设计之间建立一种平衡点，为你区分哪些设计该事先做、哪些设计该迭代时做提供了一个可靠的判断依据。

『有争议的优点』

       事实上提高了开发效率。每一个正在使用TDD并相信TDD的人都会相信这一点，但观望者则不同，不相信TDD的人甚至坚决反对这一点，这很正常，世界总是这样。
      发现比传统测试方式更多的Bug。
      使IDE的调试功能失去意义，或者应该说，避免了令人头痛的调试和节约了调试的时间。
      总是处在要么编程要么重构的状态下，不会使人抓狂。（两顶帽子）
      单元测试非常有趣。

五、TDD的优势

TDD的基本思路就是通过测试来推动整个开发的进行。而测试驱动开发技术并不只是单纯的测试工作。

需求向来就是软件开发过程中感觉最不好明确描述、易变的东西。这里说的需求不只是指用户的需求，还包括对代码的使用需求。很多开发人员最害怕的就是后期还要修改某个类或者函数的接口进行修改或者扩展，为什么会发生这样的事情就是因为这部分代码的使用需求没有很好的描述。测试驱动开发就是通过编写测试用例，先考虑代码的使用需求（包括功能、过程、接口等），而且这个描述是无二义的，可执行验证的。

通过编写这部分代码的测试用例，对其功能的分解、使用过程、接口都进行了设计。而且这种从使用角度对代码的设计通常更符合后期开发的需求。可测试的要求，对代码的内聚性的提高和复用都非常有益。因此测试驱动开发也是一种代码设计的过程。

开发人员通常对编写文档非常厌烦，但要使用、理解别人的代码时通常又希望能有文档进行指导。而测试驱动开发过程中产生的测试用例代码就是对代码的最好的解释。

快乐工作的基础就是对自己有信心，对自己的工作成果有信心。当前很多开发人员却经常在担心：“代码是否正确？”“辛苦编写的代码还有没有严重bug？”“修改的新代码对其他部分有没有影响？”。这种担心甚至导致某些代码应该修改却不敢修改的地步。测试驱动开发提供的测试集就可以作为你信心的来源。

当然测试驱动开发最重要的功能还在于保障代码的正确性，能够迅速发现、定位bug。而迅速发现、定位bug是很多开发人员的梦想。针对关键代码的测试集，以及不断完善的测试用例，为迅速发现、定位bug提供了条件。

我的一段功能非常复杂的代码使用TDD开发完成，真实环境应用中只发现几个bug，而且很快被定位解决。您在应用后，也一定会为那种自信的开发过程，功能不断增加、完善的感觉，迅速发现、定位bug的能力所感染，喜欢这个技术的。

那么是什么样的原理、方法提供上面说的这些好处哪？下面我们就看看TDD的原理。

六、TDD的原理

测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完全部功能的开发。

我们这里把这个技术的应用领域从代码编写扩展到整个开发过程。应该对整个开发过程的各个阶段进行测试驱动，首先思考如何对这个阶段进行测试、验证、考核，并编写相关的测试文档，然后开始下一步工作，最后再验证相关的工作。下图是一个比较流行的测试模型：V测试模型。

【图 V测试模型】

在开发的各个阶段，包括需求分析、概要设计、详细设计、编码过程中都应该考虑相对应的测试工作，完成相关的测试用例的设计、测试方案、测试计划的编写。这里提到的开发阶段只是举例，根据实际的开发活动进行调整。相关的测试文档也不一定是非常详细复杂的文档，或者什么形式，但应该养成测试驱动的习惯。

关于测试模型，还有X测试模型。这个测试模型，我认为，是对详细阶段和编码阶段进行建模，应该说更详细的描述了详细设计和编码阶段的开发行为。及针对某个功能进行对应的测试驱动开发。

【图 X测试模型】

基本原理应该说非常简单，那么如何进行实际操作哪，下面对开发过程进行详细的介绍。

七、测试技术　

1. 测试范围、粒度

对哪些功能进行测试？会不会太繁琐？什么时候可以停止测试？这些问题比较常见。按大师 Kent Benk 的话，对那些你认为应该测试的代码进行测试。就是说，要相信自己的感觉，自己的经验。那些重要的功能、核心的代码就应该重点测试。感到疲劳就应该停下来休息一下。感觉没有必要更详细的测试，就停止本轮测试。

测试驱动开发强调测试并不应该是负担，而应该是帮助我们减轻工作量的方法。而对于何时停止编写测试用例，也是应该根据你的经验，功能复杂、核心功能的代码就应该编写更全面、细致的测试用例，否则测试流程即可。

测试范围没有静态的标准，同时也应该可以随着时间改变。对于开始没有编写足够的测试的功能代码，随着bug的出现，根据bug补齐相关的测试用例即可。

小步前进的原则，要求我们对大的功能块测试时，应该先分拆成更小的功能块进行测试，比如一个类A使用了类B、C，就应该编写到A使用B、C功能的测试代码前，完成对B、C的测试和开发。那么是不是每个小类或者小函数都应该测试哪？我认为没有必要。你应该运用你的经验，对那些可能出问题的地方重点测试，感觉不可能出问题的地方就等它真正出问题的时候再补测试吧。

2. 怎么编写测试用例

测试用例的编写就用上了传统的测试技术。

      操作过程尽量模拟正常使用的过程。
      全面的测试用例应该尽量做到分支覆盖，核心代码尽量做到路径覆盖。
      测试数据尽量包括：真实数据、边界数据。
      测试语句和测试数据应该尽量简单，容易理解。
      为了避免对其他代码过多的依赖，可以实现简单的桩函数或桩类（Mock Object）。
      如果内部状态非常复杂或者应该判断流程而不是状态，可以通过记录日志字符串的方式进行验证。

八、Tips

很多朋友有疑问，“测试代码的正确性如何保障？是写测试代码还是写测试文档？”这样是不是会陷入“鸡生蛋，蛋生鸡”的循环。其实是不会的。通常测试代码通常是非常简单的，通常围绕着某个情况的正确性判断的几个语句，如果太复杂，就应该继续分解啦。而传统的开发过程通常强调测试文档。但随着开发节奏的加快，用户需求的不断变化，维护高层（需求、概要设计）的测试文档可以，更低层的测试文档的成本的确太大了。而且可实时验证功能正确性的测试代码就是对代码最好的文档。

软件开发过程中，除了遵守上面提到的测试驱动开发的几个原则外，一个需要注意的问题就是，谨防过度设计。编写功能代码时应该关注于完成当前功能点，通过测试，使用最简单、直接的方式来编码。过多的考虑后期的扩展，其他功能的添加，无疑增加了过多的复杂性，容易产生问题。应该等到要添加这些特性时在进行详细的测试驱动开发。到时候，有整套测试用例做基础，通过不断重构很容易添加相关特性。