对于稳定的端到端(E2E)测试,我们需要一个尽可能与外界隔离的环境。
片状测试是由于与您的代码无关的原因而失败的测试。它们使使用 E2E 作为应用程序正确性的可靠检查变得困难。在极端情况下,不稳定的测试会让您的团队忽略 E2E 结果。这可能会扼杀自动化质量控制 (QA) 的工作。
此处介绍的方法解决了测试运行中潜在问题的两大来源:
还有其他不受此方法影响的片状来源:
在我和我的团队针对专用后端容器运行测试之前,我们使用了一个非生产服务器。这种方法在我们的 E2E 解决方案的实验阶段很好。
当只有几个测试时,我们无论如何都无法根据测试结果做出决定。
然而,随着我们继续添加更多测试并生成更长的执行时间,这种方法开始分崩离析。主要问题如下:
这个问题的解决方案是为每个测试作业提供一个单独的后端服务器和数据库。如果不是 Docker,这种方法将非常具有挑战性。
Docker 容器是创建包含应用程序运行所需一切的封闭环境的完美工具:
对于您的测试,您可以准备一个专用的数据库容器,其中包含可预测的测试数据。通过这种方式,您将能够准确地重现每次 E2E 执行中的起点,从而使您的测试更加稳定。
您可以为 Docker 镜像使用不同的标签,以对测试数据库进行版本控制。同样的测试数据库也可以用在开发环境中。对于开发中的手动测试,您需要与自动化测试类似的示例实体。
如果您已经使用 Docker 来部署后端,那么重用相同的图像来运行 E2E 将非常容易。在我的团队中,我们将后端部署为容器,并提供数据库 URL 和凭证作为环境变量。
完全相同的容器版本可以部署在生产中或用于持续集成 (CI) 以运行测试——每个环境都提供正确的值来连接到数据库。
根据您的部署策略,您可以执行以下操作之一:
使用您构建的容器作为前端构建的一部分。
获取编译后的文件并确保它们可通过 HTTP 用于测试。
在我们的例子中,我们使用选项 2:我们将应用程序部署为静态文件,因此我们只创建了一个专用容器来在 E2E 作业运行期间为构建的文件提供服务。
我们使用 GitLab 作为运行 CI 的平台。 GitLab 中的每个作业都在带有您选择的图像的容器中运行。除了主容器,您还可以定义服务:与测试一起运行的附加容器。配置非常简单:
<job-name>: services: - name: <image> alias: <container-url>
可用选项类似于您在 Docker Compose 中的选项,但它们更受限制。
GitLab 配置中的一个“陷阱”是,如果您希望允许服务在测试运行期间相互访问,则将变量FF_NETWORK_PER_BUILD
设置为 1。
在某些时候,我们在一个作业中并行运行所有测试。当时,有必要实施更强大的隔离——每个测试都使用相同的后端和数据库。
为了解决这个问题,我们升级了我们的测试,主要依赖于我们在测试的before
一部分注入的随机数据。这允许测试运行不受其他线程中发生的其他更改的影响。
这种方法一开始可能有点棘手,但根据您的情况,它可能很有意义。
即使我们为每个测试作业启动一个新的数据库,我们仍然试图让我们的测试让应用程序保持与它们发现它时相同的状态。也许这有点像我们在共享环境中运行测试时遗留下来的东西。
它不再重要,但在以下情况下它仍然可以在测试开发过程中提供帮助:
在某些情况下,将服务移动到容器不是一种选择。例如:
在这两种情况下,为了隔离测试运行,您可以模拟发送到这些服务的请求。这将使不可预测的外部服务不会影响您的测试结果。这种方法的缺点是您的测试将与您的应用程序运行的上下文断开连接。
有了模拟,当这些服务的变化影响您的应用程序时,您的测试将不会捕获案例。
如果你有兴趣了解更多关于测试或其他编程相关的话题,你可以在这里注册,以便在我发布相关内容时获得更新。