TDD的替代方法

正如我们所看到的，TDD 只是以迭代的方式交付经过良好测试的代码的一种方法。把测试放在首位，确保任何功能在交付之前都经过测试和重构。在这一节中，我们将看看一些其他常见的代码测试过程。

瀑布式测试

正如我们在介绍瀑布模型时所记得的，瀑布项目的测试或验证阶段发生在实现阶段完全完成之后。到这个时候，整个项目已经交付，所有的需求已经实现。

以下是优点：

  • 瀑布项目通常结构良好，文档完善。测试计划由这些详细的文档提供指导，测试人员可以确保他们实施的所有端到端测试都覆盖了识别的用户需求。

  • 开发人员和测试人员可以依赖项目文档独立工作，无需过多沟通。这种分工允许团队轮班工作——测试人员验证功能，开发人员修复可能出现的任何错误。

以下是缺点：

  • 由于整个项目已经完成，实现后的错误往往变得更加复杂。此外，由于项目已经完全实现，修复错误可能需要更多的工程努力，尤其是在需要进行大规模更改时。

  • 如果客户需求从一开始就不明确或不清晰，一旦客户看到交付的产品并提出变更，可能会浪费大量的实现和测试工作。

  • 测试过程往往被视为一种浪费时间、消极的活动，应该尽快完成。此外，如果开发过程出现延误，可能容易在验证过程中偷工减料，导致交付一个不稳定的产品。

验收测试驱动开发（ATDD）

接受测试驱动开发（ATDD）是一种与 TDD 相关的敏捷开发过程。ATDD 涉及来自产品、工程和测试等多个学科的人员，确保开发的是正确的产品，并且以正确的方式进行开发。客户需求被转化为一系列广泛利益相关者能够理解的需求。这些需求随后被转化为自动化的接受测试，用于验证工程部门交付的内容。

ATDD 的优点如下：

  • 与 TDD 一样，在使用 ATDD 时，测试是首先编写的。每次提交或增量代码交付后，都可以运行完整的自动化接受测试套件，确保所有端到端的功能按预期工作。

  • 如果做得正确，使用 ATDD 的项目将得到业务中各种利益相关者的广泛支持，因为他们将充分了解项目的方向以及它所提供的客户价值。

ATDD 的缺点如下：

  • 编写需求的跨学科工作需要大量的沟通和协调。这可能需要大量的时间和努力，以确保各种利益相关者能够投入所需的时间和精力。

  • 这种方法可能不适用于绿地项目（Greenfield projects），即那些前期有很多未知因素的项目。对于尚未拥有 API 或数据库模型的项目，编写接受测试可能特别具有挑战性。

  • 从项目一开始就获取示例数据或数据集可能会有挑战，尤其是当这些数据由客户或第三方提供时。

与 ATDD 相关的是 行为驱动开发（BDD）。BDD 提供了如何使用业务领域语言结构化利益相关者之间对话的明确指导。我们将在第 5 章《执行集成测试》中进一步探讨 BDD。

当我们开始将测试代码与功能代码一起编写和思考时，为我们的测试代码设定成功标准非常重要。测试指标可以帮助我们实现这一目标。