测试工件环境隔离

测试工件环境隔离是某些测试的功能，其中

它是某些（但不是全部）集成测试的属性，是一种功能，如果构建出来，可以帮助实现有效的左移测试。

缺乏隔离会造成什么伤害？

我曾经构建了一些测试，这些测试运行了一个场景，大致遵循以下过程

集成测试运行了许多使用转换的示例，这些示例运行良好并产生了预期的输出。对部署在预发布环境上的应用程序进行的一些初步手动测试也未发现问题。

但是，发布后，用户开始报告许多图像损坏的问题。

这些问题无法通过集成测试重现。

集成测试在相同的图像上运行相同的代码，这些图像最终被损坏，但看起来很好。

事实证明，问题是由图像转换库与它所依赖的特定版本的系统库之间的交互造成的。集成测试中使用的容器中不存在此问题，因为测试代码的依赖项“修复”了该问题。

对于许多开发人员来说，将测试和工件在同一个环境中运行被认为是正常做法，因此这类错误的变体并不罕见。

在上面的示例中，隔离是通过将测试代码完全分离到另一个独立的 Docker 容器中实现的。

此容器运行工件容器并直接与之交互。然后可以构建工件以类似于生产环境中运行的容器，但仍可以在本地机器或 CI 中运行。

HitchStory 不必以这种方式使用，但它是根据它将与测试工件环境隔离一起使用的假设而构建的。

它用来测试自身的 storytests 也是如此，用于测试 strictyaml 的 storytests 也是如此。

（即将推出：示例 API 测试、展示测试工件环境隔离的 playwright 测试）

隔离是有代价的，而这个代价通常是速度。

与真实容器运行的真实 Web 服务器和数据库进行测试的测试，自然比在较低层级（通常被称为“皮下测试”）进行挂钩并使用速度更快的模拟（例如，sqlite 而不是 postgres）的测试启动和运行要慢得多。

对于许多类型的代码来说，测试和生产环境之间的这种环境不匹配不会造成问题。

事实上，对于高度复杂且自包含的计算代码（单元测试擅长的代码类型），维护测试工件环境隔离的开销可能远远超过其益处。

隔离对涉及复杂集成的代码的集成测试最有利。