原文：5 steps of test-driven development
  https://developer.ibm.com/articles/5-steps-of-test-driven-development/

作者 Grant Steinfeld 发表于 2020年2月6日

在这篇文章中，我将向你介绍TDD的基础概念，如果你是敏捷开发实践者，那么TDD将是你开发生涯中的最佳实践。学习TDD是什么，理解TDD的基本流程并且知道怎么用单元测试实现TDD。你将会理解为什么在开发过程中需要使用TDD。

什么是TDD

TDD颠覆了传统的开发和测试。TDD不是先写业务代码，而是先写测试代码，写业务代码来反向满足测试代码的校验。TDD规定你先写测试代码，然后实现代码直到刚刚写的测试代码通过。

在TDD中，你先写测试，观察其失败，然后实现代码直到测试通过，听起来很倒退是吧？但是，当你使用这种测试方法时，你生成的代码会更整洁，从长远来看更不容易出错。

一个单元测试要是简单的，只涵盖一小部分逻辑的测试，例如算法。单元测试应该是确定性的。这里的“确定性”的意思是单元测试不应该有副作用，比如调用提供随机或变化数据的外部 API。同理，你将使用模拟数据代替可能随时间变化的数据。

TDD的五个步骤

TDD流程中有以下五个步骤：

• 阅读、理解和处理功能或错误请求。
• 通过编写单元测试来实现需求。如果你设置了热重载，因为尚未实现任何代码，所以此时单元测试是失败的。
• 编写并实现满足要求的代码。运行所有测试，它们应该通过，如果没有通过则重复此步骤。
• 通过重构来整理你的代码。
• 重复。

下图展示了这些步骤及其敏捷、循环和迭代特征：

该工作流程有时也被称为红-绿-重构 （Red-Green-Refactoring），这个称呼来自周期内测试的状态。

• 红色阶段表示代码不起作用。
• 绿色阶段表示代码都能正常工作，但不是以最佳的方式进行。
• 蓝色阶段表示开发人员正在重构代码，但他们确信代码已被测试覆盖，这使开发人员有信心修改和改进代码。

测试驱动开发和持续集成/持续交付

(CI) 是一种开发实践，需要开发人员每天多次将代码集成到共享存储库中。然后通过自动构建验证每次嵌入，从而使团队能够及早发现问题。通过定期集成，你可以快速发现错误，并更轻松地定位它们。

TDD 产生的单元测试也是持续集成/持续交付 (CI/CD) 过程中不可或缺的一部分。 TDD 的单元测试和持续集成/持续交付管道，如 CircleCI、GoCD 或 Travis CI，它们在提交时运行所有单元测试。

测试在部署管道中运行。如果所有测试都通过，就会进行集成和部署。但是，如果任何测试失败，该过程就会停止，从而确保构建不会被破坏。

首先设置你的工具、工具链和IDE

为了进行测试驱动的开发，你需要先设置你的工具、工具链和 IDE。在我们的项目 [code pattern] 中，我们正在开发一个 Node.js 示例，这里是我们设置的关键工具：

• 用于 Node.js 和 NPM 的 nvm（Node版本管理器）：NVM 允许你运行所需的 Node.js 版本并对其进行更改，而不会影响系统node。
• 用于开发的 npm 库：
  • Jest 用于单元测试
  • ESLint用于 linting
  • Prettier用于格式化
  • Husky 和 lint-staged 用于预提交 Git hooks

如何编写失败的单元测试

以下是几种不同的方法来编写失败的单元测试。

1. 编写一个测试，引用代码中尚不存在的函数，这将导致测试失败并出现未找到的错误（例如，404 错误）。

2. 更改断言（assert）语句以使其失败。断言语句表示被测试的代码预期返回什么值；这种语句是单元测试的关键。断言语句应反映功能或错误请求的响应。

因此，要使单元测试失败，你需要编写一个断言语句，该断言会在你想要丰富的数据结构中返回一个暂时没有的值。例如，你的 JSON 返回一个人的姓名，但你的新需求需要包含该人的手机号码。你将首先编写断言语句来包含该人的手机号码，这将导致它失败。然后，你将添加业务代码来增加该人的电话号码。

或者，在现实的编码中：你的断言语句可能是：assert actualResult == {'track':'foo fighters'}。一旦生产代码（函数）被创建，编译错误被解决，404 就会消失，但实际 actualResult 返回的结果可能是像 {} 这样的空对象。接着再将函数中的返回结果硬编码为 {‘track’:‘foo fighters’}。

测试现在将通过（绿色！）。代码现在显然只是临时的，但你可以得到基本的理解。测试已正确连接到生产代码中的某个点。从那里你可以实现实际的业务逻辑，例如，读取文件/db/调用外部 API

决定何时编写单元测试

一般来说，编写单元测试有两种情况：

案例 A：你为代表简明故事的请求编写单元测试。例如，请求可能是计算特定货币兑换所支持的国家/地区数量。我做的第一件事是编写一个单元测试并看到它失败。然后，我迭代地更改代码，直到单元测试通过。

案例 B：生产中发现的一段错误代码。此错误触发的问题需要实施修复/补丁。回到货币兑换示例，代码运行时，用户期望在许多国家/地区使用 $USD，但该行为是错误的，目前只有一个国家/地区返回。 我做的第一件事是编写一个单元测试并看到它失败。然后，更正我的实现代码，直到测试通过。这不仅修复了代码并消除了错误，而且还为我提供了一个可以重复使用的单元测试，以确保这段代码保持完整。

总结

大多数程序员不使用测试驱动开发来编写代码，但他们应该这样做。测试驱动的开发可以创建更好的容错性代码。希望你从这篇博文中了解 TDD 的理念，并将其融入你的软件开发实践中。

下一步

请继续关注有关如何在 Node.js、Java 和 Python 中进行测试驱动开发的新博客文章。

资源

非常有帮助的书与文章

Using Test-Driven Development for Microservices, Bill Doerrfeld Test-driven Java development: Invoke TDD principles for end-to-end application developmnet, 2nd Edition by Farcic, Viktor Unit testing principles, practices, and patterns, Vladimir Khorikov

标签：