ruby-on-rails - Fixtures 和 Selenium and Rails(天哪？)

Question

您在 Rails 应用程序的 Selenium 测试中使用哪些数据？您是否从固定装置加载？使用现有的开发数据库？使用单独的(非 fixture )数据库？

我正在考虑我的选择。我有一个带有大型 Selenium 测试套件的 Rails 应用程序，该测试套件在修改版本的 Selenium Grid 上运行。现在，该过程的一部分是在测试套件运行之前一次加载大量固定装置。这是很多数据。其中大部分是报告从我们的生产数据库导出的信息。当我最初设置它时，我将数据从 Oracle 导出到 yaml。

现在某些报告表中的架构发生了变化，因此我当然必须重新生成 fixture 数据。它太多了，手动编辑文件是不值得的。但是，必须为每一个小的模式更改重新生成似乎效率低下——更不用说这是另一个需要记住的步骤。有没有更好的办法？

编辑:我最初打算在每次测试前加载固定装置，并在每次测试后卸载它们，就像常规的 Rails 测试一样。但由于此报告数据，加载灯具大约需要 15 分钟。有 200 多项测试，套件每 12 小时运行一次。我能弯曲时空队长!

编辑 2: 我也同意拥有这么大的固定装置是一种难闻的气味。不过，我不确定如何减少它，因为报告汇总了大量数据，而 Selenium 测试的大部分值(value)在于它们对报告进行了测试。

即使它是一小部分数据，但...它仍然是另一组数据，可以与模式更改保持协调。 (我们有一个单独的、较小的单元测试、功能测试和 [Rails] 集成测试。)

这让我回到了最初的问题 - 除了手动操作或记住每次重新生成它们之外，还有其他选择吗？

Answer 1

如果可以，最好的办法是拥有一个系统，其中每个 Selenium 测试都有自己的数据状态(即:删除和重新创建数据库表，重新插入 Bootstrap 数据，并清除缓存)。这说起来容易做起来难，而且通常只有在项目从一开始就计划好的情况下才有可能。

下一个最好的事情是为每个测试套件/运行提供一致的数据库状态。这不是很好，因为现在很有可能某些测试将取决于先前运行的测试是否成功，这使得识别真正的失败与假阴性变得更加困难。

在我看来，最坏的情况是使用静态数据库，其中每次测试运行都会改变日期。这几乎总是会导致问题，并且通常是“项目气味”。以“正确的方式”(同样是 IMO)做到这一点的关键是对任何状态/架构更改保持警惕，并将其捕获为自动化测试/构建过程的一部分。

Rails 已经通过迁移在这方面做得很好，所以请充分利用它们!在不了解您的情况的情况下，我通常会质疑是否需要针对完整数据库的快照运行 Selenium 测试。大多数数据库可以(或应该)被提取到小于 1MB 以进行自动化测试，从而使自动化模式迁移和数据重置更加高效。

我唯一一次看到大量数据库用于 Selenium 测试的“有效”原因是数据库本身包含大量“逻辑数据”，其中数据影响应用程序流(想想:数据驱动的 UI) .