介绍

测试驱动开发是确保代码经过良好测试和可重构的有效方法。基本思想是通过编写测试开始开发。这些测试清楚地记录了期望并为成功实施创建了标准。如果做得正确，您可以在编写任何代码之前清楚地定义函数的预期输入/输出。这有一些直接的好处：

• 您仔细考虑与代码交互的界面并将其设计为可测试的
• 当您开始编写代码时，您的流程不会因手动测试或单步执行执行逻辑来预测结果而中断。相反，您只需运行测试
• 通过测试成为一个令人满意的目标。将流程分解为一系列明确且可实现的里程碑使工作变得更加愉快
• 避免实施后的懒惰和过度自信，这可能会阻止您测试代码

现在您已确信这些好处，您可以按照以下步骤开始测试驱动开发 (TDD)：

1. 编写或修改测试
2. 检查测试是否失败
3. 编写最少数量的代码以使测试通过

这些步骤是循环执行的，因此您总是添加更多测试来挑战当前的实现。

最后一步，指定编写最少量的代码，如果严格遵循，事情可能会变得乏味。在确定何时适合偏离该规则之前，了解该规则存在的原因非常重要。

简单的例子

您的任务是实现函数 Add(x, y int) int。在跳转到实现并返回 x y 之前，编写最简单的测试：1 1 == 2。那么，通过测试的最简单实现是什么？只是返回 2。现在你的测试通过了！

此时，您意识到需要更多测试，因此您加快了步伐并添加了更多测试：

• 1 2 == 3
• 100 5 == 105

现在您的测试失败了，因此您需要修复实现。这次你不能只返回 3 或返回 105，所以你需要找到一个适用于所有测试的解决方案。这导致了实现： return x y.

虽然在这个简单的示例中这感觉过于乏味，但严格遵守此方法会导致您编写多个测试而不是仅仅信任您的实现。当然，您最初返回 x y 的想法是可行的，但重点是重新训练自己依赖测试而不是您自己对代码的理解。在现实世界中，您并不是唯一一个处理这段代码的人，并且不可避免地会忘记实现细节。这个过程迫使你编写更多的测试并思考更多的方法来打破简单的实现。

最终，您将获得经验并学会找到适合您遇到的不同场景的平衡点。您将恢复全速实现功能，并发现错误更少并编写更多可维护的代码。

HTTP API 的逐步 TDD

让我们进入一个使用 TDD 实现 HTTP REST API 的更复杂的示例。本分步指南使用我的 Go 框架babyapi，但这些概念可以应用于任何地方。

babyapi 使用泛型围绕 Go 结构创建完整的 CRUD API，从而使创建完整的 REST API 和客户端 CLI 变得非常容易。除此之外，babytest 包还提供了一些用于创建端到端 API 表测试的工具。在 API 级别使用 TDD 可以一次性全面测试新 API 或功能的 HTTP 和存储层。

免责声明：由于babyapi 处理大部分实现并且还用于生成测试样板，因此从技术上讲我们并不是从TDD 开始。然而，我们将看到在我们的 API 中添加对 PATCH 请求的支持有多么有益。

1. 创建一个新的Go项目
   

2. 使用babyapi的简单示例创建初始main.go
   

3. 使用 CLI 生成测试样板
   

4. 通过用预期的 JSON 填充占位符来实现每个测试
   

5. 运行测试并查看它们是否通过！

6. 由于 PUT 是幂等的，因此需要包含所有字段。为了避免这种情况，我们希望添加对使用 PATCH 请求切换 Completed 的支持。我们首先添加一个简单的测试来了解我们期望此功能的外观
   

7. 此测试失败，因为babyapi默认不支持PATCH。我们可以通过为 TODO 结构实现 Patch 来修复它。由于我们通过两个测试定义了我们的功能，因此我们最简单的实现不仅仅是设置 Completed = true 并且我们必须使用请求中的值
   

8. 现在我们可以更改 TODO 的已完成状态，但我们仍然无法使用 PATCH 来修改其他字段，如这组新测试所示
   

9. 更新补丁以设置剩余字段
   

10. 我们的测试仍然失败，因为我们总是使用请求字段更新 TODO，即使它们是空的。通过更新实现来检查空值来修复此问题
    

11. 新的 UpdateWithPatch 测试通过，但我们之前的测试失败。由于我们将 Completed 更改为 *bool，因此使用空值创建的 TODO 将显示为 null
    

12. 为 TODO 实现渲染，这样我们就可以将 nil 视为 false
    

通过测试驱动开发来实现 PATCH 功能，从而产生了一组强大的测试和良好实现的功能。由于我们首先在测试中定义 PATCH 请求的预期输入和输出，因此很容易看到由于不检查请求中的空值而导致的问题。此外，当将 Completed 类型更改为 *bool 时，我们预先存在的测试能够防止重大更改。

结论

测试驱动开发是创建经过充分测试的正确代码的有效方法。通过从测试开始，我们可以确保每段代码都被设计为可测试的，而不是让测试成为事后的想法。

如果您对采用 TDD 犹豫不决，这里有一些可以开始的想法：

• 在函数的输入/输出清晰且实现不太复杂的简单场景中尝试。您可以为可能遇到的各种输入/输出编写一个强大的表测试。清晰地了解不同的场景可以简化实施
• 如果您正在修复新的错误，那么您已经在测试中发现了差距。首先编写一个可以首先识别此错误的测试。然后，在不破坏任何现有测试的情况下使该测试通过。
• 与babyapi示例类似，您可以使用TDD进行高级API测试。一旦您定义了预期的请求/响应，您就可以恢复通常的开发流程，以实现更注重细节的部分

即使 TDD 不太适合您编写代码的方式，它仍然是您随身携带的强大工具。我鼓励您至少花一些时间尝试一下，看看它如何影响您的开发过程。