测试驱动开发译 TDD的5个步骤 _生活百科

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

作者 Grant Steinfeld发表于 2020年2月6日
在这篇文章中，我将向你介绍TDD的基础概念，如果你是敏捷开发实践者，那么TDD将是你开发生涯中的最佳实践。学习TDD是什么，理解TDD的基本流程并且知道怎么用单元测试实现TDD 。你将会理解为什么在开发过程中需要使用TDD 。
什么是TDDTDD颠覆了传统的开发和测试。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

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

编写一个测试，引用代码中尚不存在的函数，这将导致测试失败并出现未找到的错误（例如，404 错误）。
更改断言（assert）语句以使其失败。断言语句表示被测试的代码预期返回什么值；这种语句是单元测试的关键。断言语句应反映功能或错误请求的响应。

因此，要使单元测试失败，你需要编写一个断言语句，该断言会在你想要丰富的数据结构中返回一个暂时没有的值。例如，你的 JSON 返回一个人的姓名，但你的新需求需要包含该人的手机号码。你将首先编写断言语句来包含该人的手机号码，这将导致它失败。然后，你将添加业务代码来增加该人的电话号码。
或者，在现实的编码中：你的断言语句可能是：assert actualResult == {'track':'foo fighters'} 。一旦生产代码（函数）被创建，编译错误被解决， 404 就会消失，但实际 actualResult 返回的结果可能是像 {} 这样的空对象。接着再将函数中的返回结果硬编码为 {‘track’:‘foo fighters’} 。