【敏捷开发】驱动测试开发
测试驱动开发介绍
- 测试驱动开发（Test Driven Development,英文缩写TDD）是极限编程的一个重要组成部分
- 它的基本思想就是在开发功能代码之前，先编写测试代码
- 也就是说在明确要开发某个功能后
- 首先思考如何对这个功能进行测试，并完成测试代码的编写
- 然后编写相关的代码满足这些测试用例
- 然后循环进行添加其他功能，直到完成全部功能的开发。
- 代码整洁可用(clean code that works) 是测试驱动开发所追求的目标。
- 虽然TDD光大于极限编程，但测试驱动开发完全可以单独应用。
极限编程
- 极限编程诞生于一种加强开发者与用户的沟通需求，让客户全面参与软件的开发设计，保证变化的需求及时得到修正。
- 要让客户能方便地与开发人员沟通，一定要用客户理解的语言
- 先测试再编码就是先给客户软件的外部轮廓，客户使用的功能展现，让客户感觉到未来软件的样子
- 先测试再编码与瀑布模型显然是背道而驰的。
- 同时，极限编程注重用户反馈与让客户加入开发是一致的，让客户参与就是随时反馈软件是否符合客户的要求。
- 有了反馈，开发子过程变短，迭代也就很自然出现了， 快速迭代，小版本发布都让开发过程变成更多的自反馈过程。
测试驱动开发的优点
跟测试后进行的开发方式相比，它有如下好处：
- 测试驱动开发最重要的功能还在于保障代码的正确性，能够迅速发现、定位bug。针对关键代码的测试集，以及不断完善的测试用例，为迅速发现、定位bug提供了条件。
- 通过编写代码的测试用例，对其功能的分解、使用过程、接口都进行了设计。而且这种从使用角度对代码的设计通常更符合后期开发的需求。可测试的要求，对代码的内聚性的提高和复用都非常有益。因此测试驱动开发也是一种代码设计的过程。
- 写单元测试的时候，很容易就可以为一个行为写一个测试用例，让它通过，然后为另一种行为写另一个测试用例。也就是说，整个任务会被划分成很多小的任务，独立完成。如果我们不用TDD而直接实现的话，我们很容易就会同时把所有的行为都实现了。这样花的时间长，而且在这相当长的时间里面，写的代码都是没有测试 过，不能保证准确性的。相反的，用TDD的话，我们只实现要测的行为的代码。它只花费很少的时间（几分钟），而且可以马上测试。
- 为了更容易的写单元测试，我们会广泛的使用接口。这个会让单元测试代码很容易读跟写， 因为测试代码里面没有多余的数据。如果我们不用TDD而是直接写实现的话，我们经常会使用现成的类，测试为了调用现成的类， 就不得不创建很多多余的数据，创建很巨型的对象。
- 因为广泛的使用接口，我们的类之间就不会藕合，因此重用性更好。
- 发现比传统测试方式更多的Bug。
- 完工时完工。表明我可以很清楚的看到自己的这段工作已经结束了，而传统的方式很难知道什么时候编码工作结束了。
一个生动比喻
- 盖房子的时候，工人师傅砌墙，会先用桩子拉上线，以使砖能够垒的笔直，因为垒砖的时候都是以这根线为基准的。
- TDD就像这样，先写测试代码，就像工人师傅先用桩子拉上线，然后编码的时候以此为基准，只编写符合这个测试的功能代码。
- 而一个新手或菜鸟级的小师傅，却可能不知道拉线，而是直接把砖往上垒，垒了一些之后再看是否笔直，这时候可能会用一根线，量一下砌好的墙是否笔直，如果不直再进行校正，敲敲打打。
- 使用传统的软件开发过程就像这样，我们先编码，编码完成之后才写测试程序，以此检验已写的代码是否正确，如果有错误再一点点修改。
测试驱动开发的过程
- 明确当前要完成的功能。可以记录成一个 TODO 列表。
- 快速完成针对此功能的测试用例编写。
- 测试代码编译不通过。
- 编写对应的功能代码。
- 测试通过。
- 对代码进行重构，并保证测试通过。
- 循环完成所有功能的开发。
测试驱动开发的原则
- 测试隔离。不同代码的测试应该相互隔离。对一块代码的测试只考虑此代码的测试，不要考虑其实现细节（比如它使用了其他类的边界条件）。
- 一顶帽子。开发人员开发过程中要做不同的工作，比如：编写测试代码、开发功能代码、对代码重构等。做不同的事，承担不同的角色。开发人员完成对应的工作时应该保持注意力集中在当前工作上，而不要过多的考虑其他方面的细节，保证头上只有一顶帽子。避免考虑无关细节过多，无谓地增加复杂度。
- 测试列表。需要测试的功能点很多。应该在任何阶段想添加功能需求问题时，把相关功能点加到测试列表中，然后继续手头工作。然后不断的完成对应的测试用例、功能代码、重构。一是避免疏漏，也避免干扰当前进行的工作。
- 测试驱动。这个比较核心。完成某个功能，某个类，首先编写测试代码，考虑其如何使用、如何测试。然后在对其进行设计、编码。
- 先写断言。测试代码编写时，应该首先编写对功能代码的判断用的断言语句，然后编写相应的辅助语句。
- 可测试性。功能代码设计、开发时应该具有较强的可测试性。其实遵循比较好的设计原则的代码都具备较好的测试性。比如比较高的内聚性，尽量依赖于接口等。
- 及时重构。无论是功能代码还是测试代码，对结构不合理，重复的代码等情况，在测试通过后，及时进行重构。
- 小步前进。软件开发是个复杂性非常高的工作，开发过程中要考虑很多东西，包括代码的正确性、可扩展性、性能等等，很多问题都是因为复杂性太大导致的。极限编程提出了一个非常好的思路就是小步前进。把所有的规模大、复杂性高的工作，分解成小的任务来完成。对于一个类来说，一个功能一个功能的完成，如果太困难就再分解。每个功能的完成就走测试代码－功能代码－测试－重构的循环。通过分解降低整个系统开发的复杂性。这样的效果非常明显。几个小的功能代码完成后，大的功能代码几乎是不用调试就可以通过。一个个类方法的实现，很快就看到整个类很快就完成。本来感觉很多特性需要增加，很快就会看到 没有几个啦。你甚至会为这个速度感到震惊。（个人理解，是大幅度减少调试、出错的时间产生的这种速度感）
测试范围、粒度
- 对哪些功能进行测试？会不会太繁琐？什么时候可以停止测试？这些问题比较常见。按大师 Kent Benk 的话，对那些你认为应该测试的代码进行测试。就是说，要相信自己的感觉，自己的经验。那些重要的功能、核心的代码就应该重点测试。感到疲劳就应该停下来休息一下。感觉没有必要更详细的测试，就停止本轮测试。
- 测试驱动开发强调测试并不应该是负担，而应该是帮助我们减轻工作量的方法。而对于何时停止编写测试用例，也是应该根据你的经验，功能复杂、核心功能的代码就应该编写更全面、细致的测试用例，否则测试流程即可。
- 测试范围没有静态的标准，同时也应该可以随着时间改变。对于开始没有编写足够的测试的功能代码，随着bug的出现，根据bug补齐相关的测试用例即可。
- 小步前进的原则，要求我们对大的功能块测试时，应该先分拆成更小的功能块进行测试，比如一个类A使用了类B、C，就应该编写到A使用B、C功能的测试代码前，完成对B、C的测试和开发。那么是不是每个小类或者小函数都应该测试哪？个人认为没有必要。应该运用你的经验，对那些可能出问题的地方重点测试，感觉不可能出问题的地方就等它真正出问题的时候再补测试。
怎么编写测试用例
- 测试用例的编写就用上了传统的测试技术。
- 操作过程尽量模拟正常使用的过程。
- 全面的测试用例应该尽量做到分支覆盖，核心代码尽量做到路径覆盖。
- 测试数据尽量包括：真实数据、边界数据。
- 测试语句和测试数据应该尽量简单，容易理解。
- 为了避免对其他代码过多的依赖，可以实现简单的桩函数或桩类（Mock Object）。
- 如果内部状态非常复杂或者应该判断流程而不是状态，可以通过记录日志字符串的方式进行验证。
单元测试
概述
- 单元测试的目标:确保模块被正确地编码
- 由谁去做:通常由开发人员执行。
- 怎样去测试:功能测试可以用黑盒测试方法，代码测试可用白盒测试方法。
- 什么时候停止:当开发人员感到代码没有缺陷时。
单元测试的重要性
- 一个尽责的单元测试方法将会在产品开发的某个阶段发现很多的Bug，并且修改它们的成本也很低。
- 系统开发的后期阶段，Bug的检测和修改将会变得更加困难，并要消耗大量的时间和开发费用。
- 无论什么时候做出修改都要进行完整的回归测试，在生命周期中尽早的对产品代码进行测试将是效率和质量得到最好的保证。
- 在提供了经过单元测试的情况下，系统集成过程将会大大的简化。开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上，而不会陷入充满很多Bug的单元之中不能自拔。
- 使测试工作的效率发挥到最大化的关键在于选择正确的测试策略，这包含了完全的单元测试的概念，以及对测试过程的良好的管理，还有适当的使用好工具来支持测试过程。
为什么要进行单元测试
单元测试是不是太浪费时间了？
- 不经过单元测试，直接进入集成测试，系统正常工作的可能性非常低，大量的时间被花费在跟踪那些简单的Bug上，会导致集成为一个系统时增加额外的工期。
- 编写完整计划的单元测试和编写实际的代码所花费的精力大致相同。但是，一旦完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开发人员能够进行更高效的系统集成工作，这才是真正意义上的进步。
- 调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。
单元测试仅仅是为了证明这些代码作了什么吗？
- 这是那些没有首先为每个单元编写一个详细设计文档而直接跳到编码阶段的开发人员提出的一条普遍的抱怨。这样的测试完全基于已经写好的代码，这无法证明任何事情。
- 单元测试基于详细设计文档，这样的测试可以找到更多的代码错误，甚至是详细设计的错误。
- 因此，高质量的单元测试需要高质量的详细设计文档。
我是一个很棒的程序员，是不是可以不进行单元测试呢？
- 每个人都可能犯错误。
- 真正的完整的系统往往是非常复杂的，不能寄希望于没有进行广泛的测试和Bug修改过程就可以正常工作。
有集成测试就够了，集成测试将会抓住所有的Bug
- 系统规模愈来愈大，复杂度愈来愈高，没有单元测试，开发人员很可能会花费大量的时间仅仅是为了使该系统能够运行。
- 任何实际的测试方案都无法执行。
- 在系统集成阶段，对单元功能全面测试的负载程度远远的超过独立进行的单元测试过程。
- 最后的结果是测试将无法达到它所应该有的全面性，一些缺陷将被遗漏，并且很多Bug将被忽略过去。
单元测试的成本效率不高？
- 无论什么时候做出修改都要进行完整的回归测试。
- 在生命周期中尽早的对产品进行测试将使效率和质量得到最好的保证
- Bug修改越晚，费用就越高，单元测试是一个在早期抓住Bug的机会。
- 相比后阶段的测试，单元测试的创建更简单，维护更容易，并且可以更方便的进行重复。
- 从全程的测试费用来考虑，相比复杂且旷日持久的集成测试，或是不稳定的系统，单元测试所需的费用是最低的。
单元测试的策略
- 单元测试最核心的并不是工具的使用，而是测试的策略和方法。
- 工具也好，实现手段也好，只是开展单元测试的必需品。
- 以下是单元测试常采用的策略：
- 哪些是重点模块？
- 哪些程序是最复杂、最容易出错的？
- 哪些程序是相对独立，应当提前测试的？
- 哪些程序最容易扩散错误？
- 哪些程序是开发者最没有信心的？
- 80-20原则：80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错，这种应该列入测试重点。
测试用例的设计
- 单元测试的核心是测试用例的设计，测试用例的核心是测试数据的设计。
- 测试用例的设计主要从两方面考虑：
- 功能。我们为了验证一个函数是否实现了它的功能，通常采用黑盒测试的方法。常用的方法有边界值、等价类、因果图
- 逻辑结构。通常采用白盒测试的方法。常用的方法有判定覆盖、条件覆盖、条件判定组合覆盖
TDD与单元测试的区别
- TDD是一种设计手段，而不仅仅是测试手段。
- TDD的原则是“只做必要的事，不做多余的事”。
- TDD其实并不是单纯强调测试，它首先是需求分析和设计技术。
面临的问题
- 测试用例不全面
- 测试数据依赖于整个系统环境，不能回归
- 对于复杂的函数或接口的测试没有实现
- 没有建立测试基础类
- 系统更新变化快，用例不能及时更新
- 测试函数的功能不唯一
