测试驱动开发

测试驱动开发，是计算机程序敏捷开发中经常使用的一种方法。 在测试驱动开发中，程序员总是在要测试的组件之前创建软件测试。

根据经典方法，例如根据瀑布或 V 模型，测试是与要测试的系统并行且独立的，甚至是根据它开发的。 这通常意味着代码很难测试，测试工作量很大，而且它们没有达到预期或要求的测试覆盖率。 可能的原因包括：

• 系统的可测试性缺失或不足。
• 禁止公司管理层对非功能性程序部分进行投资。
• 在时间压力下或纯粹为了实现所需的测试覆盖率而创建测试。
• 程序员在创建测试时缺乏纪律。
• 白盒测试的重点是要测试的系统及其特性，以及由此产生的“绕过错误”测试。

测试驱动开发的方法试图抵消白盒测试的这些缺点，同时得到更适合软件任务和更易于维护的软件设计。

使用测试驱动开发时，平均可以检测或避免 45% 的错误。 相比之下，单独使用单元测试时，平均只能检测到 30% 的错误。

在测试驱动开发中，区分了小规模测试、模块测试（单元测试）和大规模测试（集成测试、系统测试、验收测试），Kent Beck 的方法是为单元测试而设计的。

单元测试是在实际的计算机程序之前编写的。 没有指定将执行实现的程序员是否也将创建单元测试。 允许同时存在多个失败的单元测试。 计算机程序中单元测试所要求的行为的实现可以推迟。

测试优先方法可以看作是测试驱动开发的初级阶段。

单元测试和用它们测试的单元总是并行开发的。 实际的编程是在小的、重复的微迭代中完成的。 这样的迭代应该只需要几分钟，包含三个主要部分，称为红绿重构

• 红色：编写测试以检查要编程的新行为（功能）。 你从最简单的例子开始。 如果函数较旧，这也可能是已知错误或要实现的新功能。 这个测试最初没有被现有的程序代码完成，所以它一定会失败。
• 绿色：尽可能少地更改程序代码并添加到其中，直到它在随后启动的测试运行后通过所有测试。
• 然后清理代码（重构）：删除重复（代码重复），在必要时进行抽象，使其与绑定代码约定保持一致，等等。在这个阶段，不允许有新的行为——测试不会覆盖——待介绍。 每次更改后，都会进行测试，如果失败，则不可能在所用代码中采用明显错误的更改。 整理的目的是让代码通俗易懂。

重复这三个步骤，直到已知错误得到纠正，代码提供了所需的功能，并且开发人员再也想不出任何可能仍然会失败的有意义的进一步测试。 如此处理的程序技术单元（单元）则暂时视为完成。 与她一起创建的测试将被保留，以便即使在未来发生变化后，也可以再次测试以确定已经实现的行为方面是否仍然得到满足。

为了使步骤 2 中的更改（也称为转换）实现目标，每个更改都必须导致更通用的解决方案； 例如，它不能只处理当前的测试用例而牺牲其他测试用例。 越来越详细的测试因此将代码推向越来越通用的解决方案。 遵守 Tran形成优先级通常会导致更有效的算法。

始终遵循这种方法是一种进化设计方法，每个单独的更改都会使系统进化。

在测试驱动开发中，系统测试总是在系统本身之前开发，或者至少是在指定之前。 在测试驱动开发的情况下，系统开发的任务不再像传统那样完成书面要求，而是通过指定的系统测试。

验收测试驱动开发 (ATDD) 虽然与测试驱动开发相关，但在方法上不同于测试驱动开发。 验收测试驱动开发是客户或用户、开发人员和测试人员之间的一种沟通工具，旨在确保需求得到很好的描述。 验收测试驱动开发不需要测试用例的自动化，尽管它有助于回归测试。 验收测试驱动开发中的测试对于非开发人员也必须是易读的，在很多情况下，测试驱动开发中的测试可以从验收测试驱动开发中的测试派生出来。

除了其他目标之外，所有类型的测试驱动开发都力求尽可能完整的测试自动化。 对于测试驱动开发，所有测试都必须能够轻松（“按下按钮”）并尽快执行。 对于单元测试，这意味着几秒钟的持续时间，对于验收或系统测试最多几分钟，或者仅在特殊情况下更长。

与经典方法相比，测试驱动方法的巨大优势在于：

• 您有一个布尔指标来满足要求：测试通过或失败。
• 重构，即清理代码，可以减少错误； 因为您是小步前进，并且始终基于通过的测试，所以几乎不会出现新错误，并且更容易定位。
• 因为测试可以很容易地完成并且不需要花费很多时间，所以程序员大部分时间都在正确的系统上工作，因此有信心并专注于当前的子任务。 （没有“穿越沙漠”，没有“万物相连”）
• 自动化测试记录了系统，在验收驱动开发的情况下，非开发人员甚至可以阅读。 通过测试，您同时创建了一个“可执行规范”——软件系统应该做的事情以随时可读和可执行的测试形式提供。
• 测试驱动的方法往往会导致程序代码更加模块化，并且更容易更改和扩展。 计划的系统将分小步开发，独立编写和测试，然后才集成。 相应的软件单元（类、模块……）变得更小、更具体，它们的耦合变得更松散，它们的接口也更简单。 如果您还使用模拟对象，这也会迫使您减少依赖性或使它们保持简单，因为否则无法实现测试和生产代码的基本快速和简单的模块交换。
• 实证研究表明，缺乏经验的开发人员因 TDD 而导致的缺陷率较低。 然而，这也意味着花费更多的时间。 其他实证研究无法确定质量有任何提高。 总体而言，这导致仅通过 TDD 获得的实际质量提升情况不一致。

测试驱动开发是极限编程 (XP) 和其他敏捷方法的重要组成部分。 测试驱动开发也可以在这之外找到，通常与结对编程有关。 Katas 通常用作训练方法。