自动化测试架构：为需要速度的团队提供的快速指南

大多数团队不存在“缺乏测试”的问题。测试架构不佳存在问题。

他们一开始是出于好意。有人编写了一个测试，然后又编写了另一个，几个月之内就有了一套包含数百个案例的套件。当该套件开始需要二十分钟才能运行，由于任何微小的更改而中断并且没有人再信任红色结果时，就会出现问题。自然的反应是关闭“总是失败”的测试。从此，套房就变成了剧院。

本指南很简单：在讨论使用哪个工具之前，先确定测试的架构。正是这一决定将保护团队的套件与拖慢团队速度的套件区分开来。

为什么架构先于覆盖

覆盖率是一个易于衡量且易于欺骗的指标。通过测试 getter 和 setter，您可以获得 90% 的覆盖率，而无需保护任何重要的业务规则。

真正维持速度的是测试的组织方式：每个级别测试的内容、运行速度、隔离程度以及如何清楚地指出问题所在。这是一个架构决策，而不是数量决策。

我认为它是基础设施。您不能通过随机堆叠服务器来扩展系统；而是要通过随机堆叠服务器来扩展系统。定义层次、职责和合同。测试也是如此。如果没有设计，该套件就会作为债务而不是资产增长。

测试金字塔仍然是最有用的思维模型。其基础是单元测试：许多、快速、隔离。中间是集成测试，检查各个部分是否相互通信。在顶部，很少有端到端测试，可以锻炼用户流程。

经验法则很简单。金字塔越高，测试越昂贵、越慢，而且越脆弱。这就是为什么顶部必须很窄。一个颠倒金字塔的团队，有数十个接口测试和很少的单元测试，将拥有一个缓慢且不稳定的套件。

这里最常见的错误是将金字塔视为教条。例如，在非常面向集成的系统中，例如编排服务的 API，加厚集成层是有意义的。格式比原则更重要：将验证推向最便宜的水平，但仍能提供信心。

有些选择会对套件的健康产生不成比例的影响。尽早解决这些问题是值得的。

首先是要隔离什么。单元测试必须在没有工作台、没有网络、没有真实时钟的情况下运行。当你需要上半个系统来测试某个功能时，问题不在于测试，而在于代码耦合。测试只是报告。

第二是如何处理外部依赖。模拟和存根可以加快速度，但它们撒了谎：它们测试您认为依赖项会做什么，而不是它会做什么。因此，我为关键边界、支付、[身份验证1、持久性]保留了真正的集成测试，并在其余部分谨慎使用双精度测试。

第三个是测试所在的地方。让他们靠近他们检查的代码。单独存储库中的套件几乎总是会腐烂，因为它们的变化速度与生产代码不同。

慢套件是会被忽略的套件。如果运行所有内容需要半个小时，那么开发人员将只运行其中的一部分，或者根本不运行任何内容，并且只能在 CI 传送带上发现问题，为时已晚。

实际目标是让统一层在开发过程中在几秒钟内本地运行。这需要纪律：可并行测试、不依赖共享状态、不“等待”某些事情。固定等待是真实套件中缓慢和不稳定的最大根源。

在CI中，按阶段分开。首先运行单元，快速失败，然后才继续进行集成和端到端。如果基本规则已经被打破，那么花费十分钟进行接口测试是没有意义的。

如果有一个项目破坏了对套件的信任，那么该测试有时会通过，有时会失败，而没有任何改变。这比没有测试更糟糕，因为它教会团队忽略红色。

间歇性测试几乎总是由三个来源引起：时序依赖性、执行顺序依赖性和跨案例的共享状态。解决这个问题是一项建筑工作，而不是耐心。每个测试都必须设置和清理自己的场景，而不对之前运行过的内容进行任何假设。

我将间歇性测试视为一个事件，而不是噪音。当它出现时，我要么修复它，要么删除它。在套件中保留不可靠的测试会污染所有其他测试。

这是许多团队忽视的管理愿景。测试代码就是代码。它需要审查、重构和所有权。废弃的套件的降级速度与任何其他未维护的系统相同。

在我领导的团队中，规则是测试是完成定义的一部分，而不是推到冲刺末尾的单独任务。套件的运行状况（执行时间、间歇性故障率）与我们监控的其他指标一起作为工程指标包含在内。

在公共环境和处理敏感数据的产品中，这具有另一个重要意义。可靠的套件是让您能够更改关键系统而无需祈祷任何损坏的一部分。这是治理，而不是技术奇想。

如果您的套房仍然很小，那么现在是获得正确架构的廉价时机。定义级别，确定单元测试不接触基础设施，要求隔离每个测试并将速度视为一项要求。

如果套件已经很大并且令人痛苦，请不要尝试重写所有内容。首先止血：消除间歇性的，分离 IC 中的各个阶段，并仅通过新的测试来保护经常变化的部分。剩下的你一点点进步。

目前尚不存在自动化测试来证明代码有效。它们的存在是为了给你明天改变它的勇气。本质上，一个好的测试架构可以避免对系统发展的恐惧。

如果您的团队已经进行了测试，但对它们失去了信心，那么在编写另一个案例之前值得重新审视架构。我的博客上还有关于质量和软件工程的其他文本，如果这是您组织中的真正问题，那么这种对话是有回报的。