问题描述
我遇到的问题与 E2E 测试有关，该测试将一直运行以用于新的应用程序构建（甚至可能每隔几个小时在 CircleCi 上运行）。我有（并且将来会有更多）包含大量设置的功能（每个场景运行都需要相同的设置）。例如，在场景运行之前（功能中的许多）需要一些用户、内容、配置等。在场景运行之后，最佳实践可能是删除/删除所有用户、内容等（或至少在所有场景之后已运行该功能）。我很难理解什么是最佳实践。
如果我添加一个背景，那么它会在每个场景之前运行，但是然后我会从背景中删除所有数据（我可以在最后一个场景步骤中添加一个清理功能，但这看起来很糟糕，如果我错了，这是正确的）。我可以添加将在每个场景之后清理的钩子，并继续为新功能添加更多钩子（可能使用场景标签来区分它们应该运行哪些）。
有一些选项，但确实感觉效率很低......这些测试将在实时环境中运行（不是快速的集成或单元测试，而是 E2E）。很多时候，设置/背景比一个场景需要更多的时间来运行，然后它会为每个微小的场景一遍又一遍地运行。例如，必须在例如运行后台一堆端点来创建用户，一些内容，在很多情况下（当我们还没有端点时）我将不得不通过 UI 编写一个自动化的旅程来添加一些东西或更改特定设置，然后以同样的方式添加最后删除所有内容，并通过 UI 将设置更改为功能运行之前的状态。感觉好慢，效率低下...
我想到的唯一其他事情（但可能不适用于所有情况）。是创建一个巨大的钩子脚本，我将在整个套件运行之前添加所有必要的“东西”，在整个运行之后我清理整个堆栈/实例数据库（或重置为某些预设的数据库快照）以使其状态就像之前整个套件运行一样。
请帮助我了解在这种情况下的最佳做法是什么
问候
解决方法
通常 Cuking 的想法是在每个场景后重置数据库。这是通过以下方式完成的：
- 在事务中运行场景（然后回滚）
- 在每个场景之后清空数据库
你做什么取决于你使用的是哪种口味的蛋糕。
您所说的低效率可以通过多种方式得到缓解，而不会影响在每个场景之后都应该重置数据库的想法。基本上，您可以将 Cukes 视为设置状态 (Givens) 做某事 (When) 和验证 (Thens)。仅当必须使用 UI。
因此使用 Givens，您可以通过以下任一方式设置状态
- 使用工厂或夹具直接写入数据库
- 调用服务（与您的 UI 控制器使用的服务相同）来创建事物
第二个更受欢迎。
由于大部分工作都在 UI 之外完成，这意味着您可以快速完成复杂设置。
这确实是cuking时要走的路。在不使用 UI 的情况下在 Givens 中设置所有内容（在适当的情况下使用背景），然后登录，然后在使用 UI 时执行您的操作，并使用您的 Thens 在 UI 中验证结果。
使用这种方法，我当前的项目有大约 450 个场景，在我的 Mac mini 上运行大约 5 分钟，其中包括
- 使用浏览器逐步完成 UI 向导的几个场景（超慢）
- 多个实体的复杂设置的许多场景
您必须围绕标准做法来使您的套件高效和快速的这种想法很常见，而且几乎总是错误的。
实际上你可以走得比我快得多（虽然这需要相当多的工作）