同时使用 webrat 和 capybara

发布于 2024-11-08 04:42:03 字数 831 浏览 4 评论 0原文

我一直在使用 Capybara 进行集成/请求测试,但刚刚意识到我无法用它进行视图测试。

这个答案表明 Webrat 和 Capybara 可以串联使用;但 RSpec 文档 建议必须在二。 这是另一个 github 线程,建议使用 webrat 用于视图和 capybara 进行集成。

我发现,如果我在 gemfile 中包含 Webrat,我可以毫无问题地使用 webrat 进行视图,但我的水豚风格的集成测试不再起作用。具体来说,我收到以下简单示例的错误:

it "should have a Home page at '/'" do
  visit '/'
  page.should have_selector('title', :content => "Home page")
end

我收到错误:

No response yet. Request a page first.

What's the best way(如果有的话?)让 webrat 和 capybara 互相喜欢?

I've been using Capybara for integration/request testing, but have only just realised I can't do view testing with it.

This SO answer suggests Webrat and Capybara can be used in tandem; but the RSpec docs suggest one must choose between the two. Here's another github thread that suggests webrat can be used for views and capybara for integration.

I've found that if I include Webrat in my gemfile, I can use webrat for views with no problem, but my capybara-styled integration tests no longer work. Specifically, I get an error with the following simple example:

it "should have a Home page at '/'" do
  visit '/'
  page.should have_selector('title', :content => "Home page")
end

I get the error:

No response yet. Request a page first.

What's the best way (if any?) to get webrat and capybara to like eachother?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

晨与橙与城 2024-11-15 04:42:03

通常没有理由同时使用 Webrat 和 Capybara。选择一个(可能是水豚)。视图测试是一个坏主意,一般来说没有必要;通常你的集成测试应该涵盖这个基础。

换句话说,修正你的测试策略,问题就会消失。

There's generally no reason to use both Webrat and Capybara. Pick one (probably Capybara). View tests are a bad idea and shouldn't be necessary in general; usually your integration tests should cover that ground.

In other words, fix your testing strategy and the problem will go away.

与风相奔跑 2024-11-15 04:42:03

总的来说,我同意 Marnen 的观点“只选择其中之一,可能是水豚”,但同时使用它们的一个可能原因是逐渐迁移。

假设您有一个大型测试套件,并且要将其迁移到 Capybara,但您希望让一些旧测试保持“Webrat 驱动”一段时间。

虽然,我没有找到适合这种情况的理想解决方案,但这就是我所做的:

# features/support/env.rb
...
if ENV['WITH_WEBRAT'].nil?
    require 'capybara/rails'
    require 'capybara/cucumber'
    ...
else
    require 'webrat'
    ...
end
...

# config/cucumber.yml
...
default: --profile capybara
capybara: <% std_opts %> --tags ~@webrat features
webrat:   <% std_opts %> --tags @webrat features WITH_WEBRAT=1
...

# features/webrat.feature
@webrat
...

# features/capybara.feature
...

现在,您可以执行cucumber来运行仅限水豚的测试套件或cucumber -p webrat 用于您的旧版 Webrat 功能。

不理想,但它对我有用。

In general, I agree with Marnen about "just pick one of them, probably Capybara", but one possible reason to use both of them is gradual migration.

Say, you have a large test suite and you're migrating it to Capybara, but you'd like to let some of your old tests to stay "Webrat-driven" for some time.

Although, I didn't find ideal solution for this case, here's what I did:

# features/support/env.rb
...
if ENV['WITH_WEBRAT'].nil?
    require 'capybara/rails'
    require 'capybara/cucumber'
    ...
else
    require 'webrat'
    ...
end
...

# config/cucumber.yml
...
default: --profile capybara
capybara: <% std_opts %> --tags ~@webrat features
webrat:   <% std_opts %> --tags @webrat features WITH_WEBRAT=1
...

# features/webrat.feature
@webrat
...

# features/capybara.feature
...

Now, you can do cucumber to run your capybara-only test suite or cucumber -p webrat for your legacy Webrat features.

Not ideal, but it worked for me.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文