如何开始测试驱动开发

测试驱动开发 (TDD) 是指在编写任何代码之前先编写测试。也称为红绿测试，因为你编写测试后，测试失败，然后你再编写代码使其通过。

这个过程有很多好处，例如更简单的设计、更高的测试覆盖率以及更高的代码质量。它为开发人员提供了一个可操作的结构，通常可以产生有用的编码标准。如果一个团队采用 TDD，那么所有开发人员都会为他们编写的代码编写测试。

如果你对 TDD 完全陌生，那么入门可能会有点迷茫。其实，入门其实很简单。

尝试 TDD

在理想情况下，所有功能都会提前设定好预期行为。但现实情况是，产品经理会改变主意，用例也会发生变化，预期行为也会随之改变。这给 TDD 带来了一些挑战，一开始可能会让人感到沮丧。

对于 TDD 新手来说，在功能开发完成之前就尝试编写测试可能会让他们感到困惑。由于预期行为尚未确定，TDD 会拖慢你的进度，让你感到停滞不前。很多时候，你需要随着需求的变化不断迭代测试。这并非坏事，但从这里开始可能会充满挑战。

事实上，正是这种转变导致利益相关者说“TDD 耗时太长”。事实上，TDD 的真正目的是为未来更快的开发做好准备。编写的每一个测试都是提升代码质量和加快开发速度的一步。

如果您正在处理遗留代码库，那么 TDD 实验可能就是一个 bug 的开始。每个软件都有 bug，而且它们的行为往往与预期行为和实际行为有所不同。这些都是开始应用 TDD 概念的好地方。

按照这 7 个步骤熟悉测试驱动开发。

1. 该错误必须是可重现的并且具有预期的行为。
2. 现在找到代码中错误所在的位置。
3. 创建具有预期行为的单元测试。
4. 运行新测试并发现它失败了。
5. 更新代码以产生预期的行为。
6. 再次运行新测试并查看它是否通过。
7. 对测试涵盖的代码执行任何重构。

就这样，你已经应用了 TDD 的概念。很简单吧？简直太简单了。关于其中几个步骤，我略过了几个重要的细节。

该错误必须是可重现的并且具有预期的行为

如果对于它是否是 Bug 还存在疑问，那么它就不适合用来开启你的 TDD 之旅。为什么？因为这类 Bug 的预期行为不明确，那么你的测试应该测试什么呢？

创建具有预期行为的单元测试

在已有单元测试的遗留系统中，这可能微不足道。如果你的系统尚未进行单元测试，那么你正在开辟新局面。开辟新局面意味着重构代码。为什么？因为这些代码库通常需要可测试。添加依赖注入，使类和函数单一职责，以及可能使用接口。

对测试覆盖的代码执行任何重构

这是营地的政策，请将代码保留得比刚开始的时候更好。如果您认为代码已经完美无缺，请与您的团队成员仔细核对。代码是一个活的有机体，会随着每次提交而不断演进。必须对其进行维护、清理和优化。有了良好的单元测试，您就可以进行这些维护，并知道是否破坏了不该破坏的东西。

那么功能呢？

熟悉 TDD 概念后，你也应该将其应用于新功能。流程大部分相同。有些人先编写几行功能代码，然后编写测试。有些人先编写所有测试，然后再编写功能。

很多 TDD 开发者对于这两种方法孰优孰劣有着非常不同的看法。我认为两种方法都很好，因为两种方法都可以进行测试。

需求变化了怎么办？没什么大不了的。为什么？因为如果需求变了，你更新测试，发现测试失败，然后更新代码。在功能开发之前/同时编写测试，比功能迭代要轻松得多。

结论

测试驱动开发 (TDD) 是软件开发中非常强大的工具。它使团队能够开发出可维护且高质量的代码。但它并非唯一的工具。结对编程、简短的故事和快速迭代开发也是至关重要的工具。

通过实际使用来学习 AWS

如果您喜欢这篇文章，并且渴望进一步了解 Amazon Web Services，我创建了一个关于如何在 AWS 上托管、保护和交付静态网站的新课程！这是一个包含书籍和视频的课程，可以帮助您快速学习 AWS。它提供了一个框架，让您能够通过实际操作来学习复杂的知识。

请前往登陆页面为自己获取一份副本！