固定装置，硒和滑轨(哦，我的?) [英] Fixtures and Selenium and Rails (oh my?)

问题描述

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

What data do you use with Selenium tests on Rails apps? Do you load from fixtures? Use an existing dev db? Use a separate (non-fixture) db?

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

I'm considering my options here. I have a Rails app with a large Selenium test suite that runs on a modified version of Selenium Grid. Part of the process, right now, is loading a large set of fixtures, once, before the test suite runs. It's a LOT of data. Most of it is reporting info exported from our production db. When I set it up originally, I exported the data to yaml from Oracle.

现在某些报告表中发生了架构更改，因此，我当然必须重新生成灯具数据.有太多的东西，所以不值得手动编辑文件.但是似乎每次模式更改都必须重新生成效率很低-更不用说这是要记住的又一步.有更好的方法吗?

Now there's been a schema change in some of the reporting tables, so of course I have to regenerate the fixture data. There is so much of it that it's not worthwhile to edit the files by hand. But it seems inefficient to have to regenerate for every little schema change - not to mention that it's yet another step to remember to do. Is there a better way?

编辑:我原本打算在每次测试之前加载固定装置，然后在每次测试之后像常规的Rails测试一样卸下固定装置.但是由于此报告数据，大约需要15分钟来加载灯具.有200多个测试，该套件每12小时运行一次.我会弯腰时空队长！

I originally intended to load the fixtures before each test and unload them after each test, like regular Rails tests. But it takes about 15 minutes to load the fixtures due to this reporting data. There are 200+ tests, and the suite runs every 12 hours. I cannae bend spacetime captain!

我也同意拥有大量灯具会产生难闻的气味.不过，我不确定如何缩减它，因为报告汇总了大量数据，硒测试的大部分价值在于它们可以测试报告.

EDIT 2: I also agree that having this big set of fixtures is a bad smell. I'm not sure how to pare it down, though, because the reports aggregate a lot of data and much of the value of the selenium tests is that they test the reports.

尽管只是一小部分数据，但是...仍然是另一组与模式更改保持协调的数据. (对于单元，功能和[Rails]集成测试，我们有一个单独的较小的集合.)

Even if it's a small set of data, though...it's still another set to keep co-ordinated with schema changes. (We have a separate, smaller set for unit, functional, and [Rails] integration tests.)

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

Which brings me back to my original question - are there other options besides doing it by hand, or remembering to regenerate them each time?

推荐答案

如果可以的话，最好的办法是建立一个系统，在该系统中，每个Selenium测试都会获得自己的数据状态(即:删除并重新创建数据库表，重新插入引导数据，并清除缓存).这说起来容易做起来难，通常只有在项目从一开始就计划好之后，才可能做到.

If you can, the best possible thing to do is have a system in which each Selenium test gets it's own data state (ie: DB tables dropped and recreated, bootstrap data re-inserted, and caches cleared). This is easier said than done and usually is only possible if the project planned for it from the start.

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

The next best thing is to have a consistent DB state for each test suite/run. This is not as nice since there is now a strong chance that some tests will depend on the success of previously run tests, making it more difficult identify true failures vs. false negatives.

最糟糕的情况IMO是使用静态DB，其中每个测试运行都会更改日期.这几乎总是导致问题，并且通常是项目气味". 正确方式"(同样是IMO)做到这一点的关键是要警惕任何状态/架构更改，并将其捕获为自动化测试/构建过程的一部分.

The worst case, IMO, is to use a static DB in which each test run mutates the date. This almost always leads to problems and is usually a "project smell". The key to doing it the "right way" (again, IMO) is to be vigilant about any state/schema change and capture it as part of the automated test/build process.

Rails在Migrations上已经做得很好，所以请充分利用它们！在不知道您的情况的情况下，我通常会质疑是否需要对整个数据库的快照运行Selenium测试.可以(或应该)将大多数数据库精简到1MB以下以进行自动测试，从而使自动模式迁移和数据重置更加高效.

Rails does a good job with this already with Migrations, so take advantage of them! Without knowing your situation, I'd generally question the need to run Selenium tests against a snap of the full DB. Most DBs can (or should) be distilled down to less than 1MB for automated testing, making automated schema migrations and data reset much more efficient.

我唯一看到大型数据库进行Selenium测试的有效"理由是，数据库本身包含大块逻辑数据"，其中数据会影响应用程序流程(认为:数据驱动的UI)

The only time I've seen a "valid" reason for massive DBs for Selenium tests is when the DB itself contains large chunks of "logic data" in which the data affects the application flow (think: data-driven UI).

这篇关于固定装置，硒和滑轨(哦，我的?)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！