从测试驱动开发和生产环境测试中获得反馈

作者 | Ben Linders

译者 | 刘雅梦

Ola Hast 和 Asgaut Mjølne Söderbom 在他们在伦敦 QCon关于结对编程的持续交付的演讲中提到，团队依赖于强大的单元测试和集成测试，而不是端到端的测试。使用 TDD（测试驱动开发）、结对编程和良好的设计，他们经常发布小的更改，在生产环境中测试真实的反馈，并使用功能开关来降低风险。

Hast 提到，他们信任他们的单元测试和集成测试，并且把它们作为一个整体。他们没有端到端测试：

我们通过使用良好的关注点分离、模块化、抽象、低耦合和高内聚来实现这一点。这些机制与 TDD 和结对编程相辅相成。结果是一个具有高代码质量的更好的领域驱动设计。

以前，他们有更多的 HTTP 应用程序集成测试，测试整个应用程序，但他们已经从这个（或只有一些愉快的案例）转向了更专注的测试，这些测试有更短的反馈循环，Hast 提到。

由于测试环境总是近似生产环境，并且通常与长供应链和糟糕的测试数据作斗争，他们或多或少已经停止使用它们了，Mjölne Söderbom 解释说：

我们更喜欢在生产环境中测试，因为在那里我们可以得到最高质量的反馈。

他们通过将新功能放在开关后面，并一次部署一小部分来降低风险。这是他们已经做了好几年的事情，而且效果非常好，Mjölne Söderbom 说。如果生产环境中出现故障，很容易找到、修复和回滚 / 前进，他补充说。

在之前的文章中，Hast 和 Mjølne Söderbom 提到他们的团队 使用 TDD 进行结对和 mob 编程；没有单独的任务或单独的代码审查。这种方法提高了代码质量，减少了浪费，并促进了知识的共享：

经过多年的实践，我们最终一起工作，进行 TDD，然后部署到生产环境。我们很少在本地或测试环境中测试应用程序。这从来不是我们的主要意图；这只是我们工作方式的一个（愉快的）结果。

结对编程和持续集成可以相辅相成。每天多次向主服务器推送是很困难的，这会导致延迟、大型 PR 和合并问题。结对使即时代码审查、更容易的重构、更少的错误和更高的团队韧性成为可能，Hast 和 Mjølne Söderbom 解释说。

Hast 提到他们过去有更多的测试，测试整个应用程序的运行，但他们已经将这个减少到最低；他们通常只有一条愉快的路径测试，以及针对任何特殊错误情况的额外测试：

我们不能用单元测试中测试的东西，我们更喜欢在生产环境中测试。测试总是现实的近似，我们总是与长供应链和糟糕的测试数据作斗争。我们总是从生产环境中得到最好的反馈。停止使用测试环境本身从来不是一个目标，但它只是另一个令人愉快的副作用。

最重要的是建立反馈循环，Mjølne Söderbom 提到。反馈有助于导航和选择方向，必要时改变方向：

我们从我们的测试中得到最快的反馈，从生产环境中得到最好的反馈。

当某件事情很痛苦时，他们会更频繁地这样做，Hast 解释说：

我们公司今天之所以能走到这一步，是因为我们增加了部署到生产环境的频率，并在问题最严重的地方迅速得到反馈，然后修复了这些问题。这个过程已经持续了 10 年。

我们非常专注于开发过程中所有级别的快速反馈循环，Mjølne Söderbom 说。TDD 是我们获得早期和快速反馈的最重要的工具之一，他解释说：

如果你的代码难以测试，通常意味着设计有问题。代码与我们“对话”，并驱动设计。

许多人认为 TDD 是一个测试工具，但实际上，它是一个设计工具。Mjølne Söderbom 总结说，拥有适当的测试来实现快速流动是一个（非常好的）副作用。

https://www.infoq.com/news/2026/02/feedback-TDD-production/