敏捷软件开发ASD-04-TDD原理与技术.pptVIP

测试驱动的软件开发 尹俊文 国防科学技术大学计算机学院 Agenda TDD的基本思想 TDD的基本概念 TDD的模式 TDD的一些问题 测试工具 1 基本思想 1.1 测试的传统视图 测试的目的是什么？ “More than the act of testing, the act of designing tests is one of the best [defect] preventers known … The thought process that must take place to create useful tests can discover and eliminate problems at every stage of development” ——Boris Beizer 1.2 测试的改进视图 1.3 测试优先 书写代码之前，先创建测试用例 “我们只有在有一个测试没有通过的时候才会写新代码！” 什么是测试驱动的开发？ 书写代码之前先写测试 结果形成了一个”刚刚好”的设计： 开发人员首先考虑的是如何使用这个组件、为什么需要这个组件、这个组件是用来干什么的？ 然后才考虑如何实现这个组件。 因此，测试驱动的开发既是一种测试技术，同时还是一种设计技术 组件是易于测试的 组件是易于增强、易于扩展和易于改写的。 没有代码是没有测试的！！ 1.4 测试驱动开发的动机 在系统开发完成之后，可能已经没有时间测试了。 那就先写测试代码吧！ 如果事情越来越复杂，可能害怕系统无法工作 那就执行测试，得到一个积极的反馈吧！哪怕是系统不工作！ 如果性能稍后才考虑，那么就不要向系统增加哪怕是一点性能 性能测试可以重用单元测试 1.5 测试驱动开发的视图 测试驱动开发过程 1.6 Test A Little, Code A Little 不需要首先编写所有的测试用例 仅仅需要编写当前的代码不会通过的一个测试 编写可以通过测试的用例 返回第一步 如果难以编写测试，那么就是设计的问题！ 每一轮的测试和编码都可能包含对以前代码的重构（下一讲的内容） “测试(red)-通过(green)-重构”循环 1.7 Why Test Driven Development? 软件开发中的最大问题是需求不明确 使用自然语言描述所导致的一个直接的结果就是A (例如，”系统必须快速处理……”) 而测试用例是没有歧义的！ 测试用例是需求的无歧义“代理人” 测试驱动开发的优势 逐渐建立一套全面的（很有希望是自动化的）测试用例?? 每次编译代码时都执行一次这套用例 所有测试必须通过，除非有了一个全新的测试 代码可以很自信地重构 在系统和集成测试期间节省时间 绝大多数测试可以自动运行 在系统测试之前可以发现许多集成错误 2 基本概念 支架 测试双(test double) 状态与基于交互的测试 2.1 支架 支架是用于测试的环境(Context) 直接由遍布在测试用例类中的配置状态形成 这些配置状态主要是指虚拟机运行时状态，包括一些静态变量和类装载时通过静态初始化创建的对象 支架主要是消除冗余 清白支架——测试用例中的所有配置行为 存在反模式的嫌疑——易读性差 更关注测试本身 2.2 测试双 最困难的测试是在测试一个类时，必须处理与之协作或者它所依赖的类的关系，这些类通常： 运行太慢，或者 暂时不可用，或者 配置复杂，难以实例化 我们通常使用一个类来模仿依赖类的行为，这个模仿其他类的类称为测试双 测试双通常具有与依赖类相同的接口，这样通常可以带来许多优势 比如，独立开发，快速开发 2 TDD的模式 TDD的模式 TDD有一些重要的准则： Isolated Test Test List 也形成了众多的模式，主要体现在： Red Bar 模式 测试模式(Testing Patterns) Green Bar 模式 2.1 Red Bar Patterns 用于回答以下问题： 什么时候写测试？ 在什么地方写测试？ 什么时候停止写测试？ One Step Test 每次测试都应该表明向系统的整体目标前进了一步。 步子有大有小，与编写测试者的经验、项目的特点以及测试者对项目的理解与计划有关 可以自顶向下测试，它可以描述整个计算的一种简单情形 也可以自下而上测试，这样可以积少成多 Starter Test 启动一次测试之前，必须回答如下问题： 这个操作属于哪里？ 什么是正确的输入？ 给定这些输入是正确的输出是什么？ 输入必须尽可能的小，以便于准确理解输入和含义以及输入与输出之间的关系 Learning Test 对外部所产生软件的学习方法 先对需要使用的工具进行测试 编写测试就是一种工具使用法的学习 测试结果的观察有助于理解外部工具的行为(语义)特征