(译)TDD(测试驱动开发)的5个步骤

  原文: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流程中有以下五个步骤:

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

下图展示了这些步骤及其敏捷、循环和迭代特征:
《(译)TDD(测试驱动开发)的5个步骤》

该工作流程有时也被称为红-绿-重构 (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 库:

如何编写失败的单元测试

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

  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

    原文作者:Iannnnnnnnnnnnn
    原文地址: https://www.cnblogs.com/Iannnnnnnnnnnnn/p/16823294.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞