我在考虑我的选择.我有一个带有大型Selenium测试套件的Rails应用程序,它运行在Selenium Grid的修改版本上.现在,部分过程是在测试套件运行之前加载一大套灯具.这是很多数据.其中大部分是从我们的生产数据库导出的报告信息.当我最初设置它时,我将数据从Oracle导出到yaml.
现在一些报告表中的模式发生了变化,所以当然我必须重新生成夹具数据.有太多的东西,手动编辑文件是不值得的.但是,为每一个小的架构变化进行重新生成似乎效率低下 – 更不用说这是另一个值得记住的步骤.有没有更好的办法？
编辑：我原本打算在每次测试之前加载灯具,并在每次测试后卸载它们,就像常规的Rails测试一样.但由于此报告数据,加载灯具大约需要15分钟.有200个测试,套件每12小时运行一次.我可以弯曲太空船长！
编辑2：我也同意拥有这么大的装置是难闻的气味.我不知道如何削减它,因为报告汇总了大量数据,而硒测试的大部分价值在于他们测试报告.
即使它只是一小部分数据,但它仍然是另一套与架构变化保持协调的集合. (我们有一个单独的,较小的单元,功能和[Rails]集成测试集.)
这让我回到原来的问题 – 除了手工制作还是记得每次重新制作它们之外还有其他选择吗？
解决方法
下一个最好的事情是为每个测试套件/运行提供一致的DB状态.这不是很好,因为现在很有可能某些测试将取决于先前运行测试的成功,使得识别真实失败与错误否定更加困难.
最坏的情况,IMO,是使用静态DB,其中每个测试运行都会改变日期.这几乎总是导致问题,通常是“项目气味”.以“正确的方式”(再次,IMO)做到这一点的关键是要对任何状态/架构变化保持警惕,并将其作为自动化测试/构建过程的一部分进行捕获.
Rails在迁移方面做得很好,所以要充分利用它们！在不了解您的情况的情况下,我通常会质疑是否需要针对完整数据库的快照运行Selenium测试.对于自动化测试,大多数DB可以(或者应该)被提取到小于1MB,从而使自动化模式迁移和数据重置更加高效.
我唯一一次看到大量数据库用于Selenium测试的“有效”原因是数据库本身包含大量“逻辑数据”,其中数据影响应用程序流(想想：数据驱动的UI).