完善自动化测试：在现代测试套件中平衡速度和可靠性

传统上，自动化测试分为单元测试、集成测试和端到端测试。这种分类是基于测试的范围，尽管不同类型之间的区别并不总是很清楚。单元测试的范围很窄，通常测试单个方法或类。集成测试验证不同组件之间的交互。端到端测试通常在平台或 Web 应用程序上执行完整的用户流程，涉及多个不同的系统。

随着代码库的增长，缓慢且不稳定的测试开始影响开发人员的生产力。从另一个维度(速度和确定性)检查测试套件是有启发性的。

缓慢和非决定论的根源

通过直觉和经验，我们知道端到端测试和集成测试比单元测试更慢、更不稳定，但为什么会这样呢?让我们考虑一下测试运行的环境。

单线程或进程

当测试在单个进程中运行时，被测试的代码也在同一进程中运行。这阻止了在单独的进程中创建服务器或数据库并在测试中连接到它们。依赖于服务器或数据库的测试必须使用模拟或伪造。

这些测试不会进行任何阻塞的进程间 I/O 调用，从而消除了缓慢和不确定性的主要根源。

单机

一些测试跨多个进程运行，在测试代码的不同进程中启动数据库和服务器，并对它们进行阻塞调用。他们甚至可以在同一台机器上进行网络调用。

测试代码现在依赖于其他进程才能可靠运行，但情况可能并不总是如此。现在，测试代码在进行 API 调用时会受到操作系统调度程序和其他因素的影响。尽管与单线程测试相比，这会带来一些缓慢和不稳定的情况，但限制在一台机器上仍然会阻止测试对其他机器进行远程调用，这是不确定性的最大来源。这让我们……

多台机器

这些测试的运行实际上没有任何限制。特别是随着云环境成为 SaaS 应用程序的常态，测试套件可以启动多个云资源并跨多个虚拟机运行完整的系统测试。由于测试现在有多个依赖项，因此即使一个组件出现故障也会影响整个测试。

设计测试套件

一个好的测试套件有几个好处：

1. 可维护性——经过良好测试的代码更易于维护，允许开发人员添加新功能、修复错误和重构代码，而不必担心无意中破坏不相关的代码。

2. 文档– 鉴于有关服务或功能的文档很容易过时，编写良好的测试通常是理解代码行为的最佳方法。

3. 干净的 API – 黑盒测试确保被测代码公开正确的 API 接口。

4. 覆盖范围——广泛的测试覆盖范围使工程和非工程利益相关者(包括销售和市场推广团队)对发布过程充满信心。

为了使测试套件有效且可靠，同时提高开发人员的工作效率，它必须最大限度地减少缓慢和不确定性。单元测试、集成测试和端到端测试之间的界限也可能是模糊的。因此，在为系统设计测试套件时，根据测试使用的资源来考虑测试会很有帮助。

Mike Cohn 的测试金字塔为思考如何构建不同类别的测试提供了一个很好的起点。这里我们也用它来类比基于范围的测试和基于环境的测试。

结论

· 大多数测试应该是快速且可靠的单线程测试，针对狭窄的代码部分。

· 您的一些测试应该是单机测试，引入不同的本地依赖项并测试不同组件如何相互交互。

· 很少有测试应该跨远程计算机运行，从而练习应用程序的端到端流程。

这种结构倾向于在广泛的覆盖范围、最大化速度和最小化片状性之间取得适当的平衡，从而形成有效的测试套件。