固定装置和Selenium和Rails（哦，我的？）

Question

您对Rails应用上的Selenium测试使用了哪些数据？您是否从灯具加载？使用现有的dev db？使用单独的（非夹具）db？

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

现在某些报告表中存在架构更改，因此我必须重新生成灯具数据。有太多的东西，手动编辑文件是不值得的。但是，为每一个小的架构变化进行重新生成似乎效率低下 - 更不用说这是记住要做的又一步。还有更好的方法吗？

编辑：我原本打算在每次测试之前加载灯具，并在每次测试后卸载它们，就像常规的Rails测试一样。但由于此报告数据，加载灯具大约需要15分钟。有200多个测试，套件每12小时运行一次。我可以弯曲太空船长！

编辑2：我也同意拥有这么大的灯具是难闻的气味。不过，我不确定如何削减它，因为报告汇总了大量数据，而硒测试的大部分价值在于他们测试报告。

即使它只是一小部分数据，但它仍然是另一套与架构变化保持协调的设置。 （我们有一个单独的，较小的单元，功能和[Rails]集成测试集。）

这让我回到原来的问题 - 除了手工操作还是记得每次都重新生成它们还有其他选择吗？

Answer 1

如果可以，最好的办法是建立一个系统，每个Selenium测试都有自己的数据状态（即：删除和重新创建数据库表，重新插入引导数据，清除缓存）。这说起来容易做起来，通常只有项目从一开始就计划好了。

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

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

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

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

Answer 2

我认为你在这里问两个相互交织的问题，所以如果我要分解它：

• 您希望快速将测试数据导入和导出数据库，并且固定装置不会为您执行此操作。
• 您已经被模式更改所困扰，并且您希望确保无论您做什么都不需要八次迭代主题为“摆弄测试数据......仍然”：）

你在这里有几个替代方案，我在下面进行了介绍。因为您已经提到过Oracle我在这里使用Oracle技术，但对于其他数据库平台（例如Postgresql）也是如此：

1. Rake tesks调用PL / SQL脚本来生成数据，令人讨厌的可怕的邪恶想法，除非没有其他选择，否则不要这样做。我在一个需要加载数十亿行的项目中进行了一些基础架构架构测试。我仍然生气。
2. 将您的数据库转换为转储格式。对于快速二进制转储，请检查exp / imp和数据泵实用程序。这将允许您快速设置和拆除数据库。当然，在我工作的rails项目中，我们使用rake任务来exp / imp一个在一分钟内有大约300k记录的数据库。还要检查作为逻辑转储实用程序的SQL Loader，因为它的逻辑较慢，并且需要您拥有控制脚本来帮助SQL Loader了解转储。但是，逻辑转储的好处是您可以在它们上运行转换脚本以将数据按到最新格式。遗憾的是，就像灯具一样，所有这些工具都对架构的变化非常敏感。
3. 使用Machinist或Factory Girl等插件可以更好地生成数据。您仍然会因使用ActiveRecord设置数据库而受到惩罚，但这些虚假对象生成器将帮助您保持接近迁移的速度，并且维护的难度远远低于固定装置。
4. 结合方法2和3.这里发生的是你用Machinst做一些测试数据。您将该测试数据导出到转储，然后在每次测试运行期间重新加载转储。架构更改时更新Machinist配置并重新导出。

希望有所帮助。

Answer 3

我目前正处于一个拥有巨大Selenium测试套件的项目中 - 实际上，一个Selenium Grid是为之编写的 - 我们的测试使用少量参考数据（尽管我们不使用Rails YAML灯具）和对象工厂用于特定测试所需的一次性数据。

或者，在我参与过的许多ThoughtWorks Rails项目中，我们编写了包含许多预提交挂钩的签入脚本 - 例如，在允许提交之前运行测试。您可能会考虑尝试的一件事是编写（或自定义）类似的签入脚本，该脚本将检查架构更改并根据需要重新加载参考数据。

参见例如保罗格罗斯在Github的rake commit tasks。