# 什么是测试驱动开发（TDD）？ 实例教程 > 原文： [https://www.guru99.com/test-driven-development.html](https://www.guru99.com/test-driven-development.html) ## 什么是测试驱动开发？ **测试驱动开发（TDD）**首先，开发了测试，该测试指定并验证代码将执行的操作。 简单来说，测试用例是在编写代码之前创建的。 TDD 的目的是使代码更清晰，简单且无错误。 测试驱动开发始于为应用程序的每个小功能设计和开发测试。 TDD 指示开发人员仅在自动测试失败时才编写新代码。 这样可以避免重复代码。 TDD 的完整形式是测试驱动的开发。  TDD 的简单概念是在编写新代码之前（开发之前）编写并纠正失败的测试。 这有助于避免重复代码，因为我们一次编写少量代码以通过测试。 （测试只不过是我们需要测试以实现它们的需求条件）。 测试驱动开发是在实际开发应用程序之前开发和运行自动化测试的过程。 因此，TDD 有时也称为**测试优先开发。** 在本教程中，您将了解有关- * [如何执行 TDD 测试](#2) * [TDDVs。 传统测试](#3) * [什么是接受 TDD 和开发者 TDD](#4) * [通过敏捷模型驱动开发（AMDD）扩展 TDD](#5) * [测试驱动开发（TDD）与。 敏捷模型驱动开发（AMDD）](#6) * [TDD](#7) 的示例 * [TDD 的好处](#8) ## 如何执行 TDD 测试 以下步骤定义了如何执行 TDD 测试， 1. 添加测试。 2. 运行所有测试，然后查看是否有任何新测试失败。 3. 编写一些代码。 4. 运行测试和重构代码。 5. 重复。  **TDD 周期定义了** 1. 编写测试 2. 使它运行。 3. 更改代码以使其正确，即重构。 4. 重复过程。 **关于 TDD 的一些说明：** * TDD 既不涉及“测试”也不涉及“设计”。 * TDD 并不意味着“编写一些测试，然后构建一个通过测试的系统。 * TDD 并不意味着“进行大量测试”。 ## TDDVs。 传统测试 TDD 方法主要是一种规范技术。 它确保您的源代码已在确认级别上经过了全面测试。 * 使用传统测试，成功的测试会发现一个或多个缺陷。 与 TDD 相同。 当测试失败时，您就可以取得进步，因为您知道需要解决该问题。 * TDD 可确保您的系统实际上满足为此定义的要求。 它有助于建立您对系统的信心。 * 在 TDD 中，更侧重于验证测试是否可以正常进行的生产代码。 在传统测试中，更多的重点放在测试用例设计上。 测试是否将显示应用程序的正确/不正确执行以满足要求。 * 在 TDD 中，您可以达到 100％的覆盖率测试。 与传统测试不同，每一行代码都经过测试。 * 传统测试与 TDD 的结合导致了测试系统而不是完善系统的重要性。 * 在敏捷建模（AM）中，您应该“有目的地进行测试”。 您应该知道为什么要测试某些东西以及需要测试什么级别。 ## 什么是接受 TDD 和开发者 TDD TDD 有两个级别 1. **验收 TDD（ATDD）：**使用 ATDD 编写单个验收测试。 该测试满足规格要求或满足系统性能。 之后，只需编写足够的生产/功能代码即可完成该验收测试。 验收测试侧重于系统的整体行为。 ATDD 也被称为**行为驱动开发（BDD）。** 2. **Developer TDD:** With Developer TDD you write single developer test i.e. unit test and then just enough production code to fulfill that test. The unit test focuses on every small functionality of the system. Developer TDD is simply called as **TDD.** ATDD 和 TDD 的主要目标是在及时（JIT）的基础上为您的解决方案指定详细的可执行要求。 JIT 意味着仅考虑系统中需要的那些需求。 因此提高效率。  ## 通过敏捷模型驱动开发（AMDD）扩展 TDD TDD 非常擅长详细的规范和验证。 它无法考虑更大的问题，例如总体设计，系统使用或 UI。 AMDD 解决了 TDD 无法解决的敏捷扩展问题。 因此 AMDD 用于更大的问题。 **AMDD 的生命周期。**  在模型驱动开发（MDD）中，在编写源代码之前会创建大量模型。 哪个又有敏捷方法？ 在上图中，每个框代表一个开发活动。 设想是 TDD 预测/想象测试的过程之一，它将在项目的第一周内进行。 构想的主要目标是确定系统范围和系统体系结构。 完成高层需求和体系结构建模以实现成功的构想。 在此过程中，没有完成软件/系统的详细说明，而是探索软件/系统的需求，该需求定义了项目的整体策略。 1. **迭代 0：预想** 有两个主要的子激活。 1. **Initial requirements envisioning.** 确定系统的高级要求和范围可能需要几天的时间。 主要重点是探索使用模型，初始域模型和用户界面模型（UI）。 2. **Initial Architectural envisioning.** 识别系统的架构也需要几天的时间。 它允许为项目设置技术指导。 主要重点是探索技术图，用户界面（UI）流程，域模型和变更案例。 2. **Iteration modeling:** 在这里，团队必须计划每次迭代要完成的工作。 * 敏捷过程用于每次迭代，即在每次迭代期间，将优先添加新的工作项。 * 首先将考虑较高优先级的工作。 添加的工作项目可以随时重新确定优先级或从项目堆栈中删除。 * 团队讨论了他们将如何实现每个需求。 为此使用建模。 * 对要为该迭代实现的每个需求进行建模分析和设计。 3. **Model storming:** 这也称为即时建模。 * 在这里的建模会议中，由 2/3 的成员组成的小组讨论纸质或白板上的问题。 * 一个团队成员将要求另一个与他们建模。 建模过程大约需要 5 到 10 分钟。 团队成员聚集在一起共享白板/纸的地方。 * 他们会探索问题，直到找不到导致问题的主要原因。 及时地，如果一个团队成员发现了他/她想要解决的问题，那么他/她将迅速寻求其他团队成员的帮助。 * 然后，其他小组成员探讨该问题，然后每个人都像以前一样继续进行。 这也称为站立建模或客户质量检查会议。 4. **测试驱动开发（TDD）。** * 它促进了对您的应用程序代码和详细规范的确认测试。 * 接受测试（详细要求）和开发人员测试（单元测试）都是 TDD 的输入。 * TDD 使代码更简单明了。 它允许开发人员维护较少的文档。 5. **评论。** * 这是可选的。 它包括代码检查和模型审查。 * 可以为每个迭代或整个项目完成。 * 这是为项目提供反馈的好选择。 ## 测试驱动开发（TDD）与。 敏捷模型驱动开发（AMDD） | **TDD** | **AMDD** | | * TDD 缩短了编程反馈循环 | * AMDD 缩短了建模反馈循环。 | | * TDD 是详细规格 | * AMDD 解决更大的问题 | | * TDD 促进了高质量代码 的发展 | * AMDD 促进与利益相关者和开发人员的高质量沟通。 | | * TDD 与程序员对话 | * AMDD 与业务分析师，利益相关者和数据专业人员进行了交谈。 | | * TDD 非视觉导向 | * AMDD 视觉定位 | | * TDD 仅限于软件作品 | * AMDD 的范围很广，包括利益相关者。 它涉及努力达成共识 | | * 都支持进化发展 | **--------------------------------------------** | ## TDD 的示例 在此示例中，我们将定义一个类密码。 对于本课程，我们将尝试满足以下条件。 密码接受的条件： * 密码应在 5 到 10 个字符之间。 首先，我们编写满足以上所有要求的代码。  **场景 1** ：要运行测试，我们创建类 PasswordValidator（）;  我们将在类 TestPassword（）之上运行； 输出通过，如下所示； **输出**：  **场景 2** ：在这里我们可以在方法 TestPasswordLength（）中看到不需要创建类 PasswordValidator 的实例。 实例表示创建类的[对象](/java-oops-class-objects.html)以引用该类的成员（变量/方法）。  我们将从代码中删除类 PasswordValidator pv = new PasswordValidator（）。 我们可以直接通过 **PasswordValidator 调用 **isValid（）**方法。 IsValid（“ Abc123”）**。 （见下图） 因此，我们重构（更改代码）如下：  **场景 3** ：重构后，输出显示失败状态（请参见下图），这是因为我们已删除该实例。 因此，没有引用[非静态](/java-static-variable-methods.html)方法 **isValid（）。**  因此，我们需要通过在布尔值之前添加“静态”字词作为公共静态布尔值 isValid（字符串密码）来更改此方法。 重构类 PasswordValidator（）以消除上述错误，以通过测试。  **输出：** 在对类 PassValidator（）进行更改后，如果我们运行测试，则输出将通过，如下所示。  ## TDD 的优势 * **Early bug notification.** 开发人员测试他们的代码，但是在数据库世界中，这通常包括手动测试或一次性脚本。 随着时间的流逝，使用 TDD 可以建立一套自动化测试，您和任何其他开发人员都可以随意重新运行。 * **更好的设计，更干净和更可扩展的代码。** * 它有助于了解如何使用代码以及如何与其他模块交互。 * 这样可以带来更好的设计决策和更可维护的代码。 * TDD 允许编写具有单一职责的较小代码，而不是具有多个职责的整体过程。 这使代码更易于理解。 * TDD 还强制仅编写生产代码以根据用户要求通过测试。 * **重构**的信心 * 如果重构代码，则代码中可能会有断点的可能性。 因此，拥有一套自动化测试，您可以在发布前修复这些漏洞。 如果在使用自动测试时发现中断，将给出适当的警告。 * 使用 TDD 可以使代码更快，可扩展性更高，而错误更少，可以以最小的风险进行更新。 * **Good for teamwork** 在没有任何团队成员的情况下，其他团队成员可以轻松地接管代码并进行工作。 它还有助于知识共享，从而使团队整体上更有效率。 * **Good for Developers** 尽管开发人员必须花更多的时间来编写 TDD 测试用例，但调试和开发新功能所花的时间却少得多。 您将编写更简洁，更简单的代码。 **摘要：** * TDD 代表测试驱动的开发。 这是修改代码以通过先前设计的测试的过程。 * 它更强调生产代码而不是测试用例设计。 * 测试驱动的开发是修改代码以通过先前设计的测试的过程。 * 在软件工程中，有时称为**“测试优先开发”。** * TDD 包括重构代码，即在不影响代码行为的情况下在现有代码中更改/添加一些代码。 * 使用 TDD 时，代码变得更加清晰和易于理解。 本文由 **Kanchan Kulkarni** 提供