# This helper allows you to reliably highlight text within a given Element by # simulating mouse actions. # module Features module HighlightContentHelper def highlight_content(node) height = node.native.rect.height width = node.native.rect.width page.driver.browser.action .move_to(node.native, -(width / 2), -(height / 2)) .click_and_hold .move_by(width, height) .release .perform end

rendered.should have_selector("#header") do |header| header.should have_selector("ul.navlinks") end Both of which silently pass - however, capybara doesn't support a :content option (it should be :text), and it doesn't support passing blocks to have_selector (a common mistake from Webrat switchers).

Capybaras ancestor and sibling methods are called on an element and take the same parameters as find. They are implemented by locating all elements that match the passed in parameters and intersecting that with the set of ancestor or sibling elements respectively.

click_link('Create Account', match: :first) It's better than first(:link, 'Create Account').click as it will wait till at least one Create Account link will appear on the page. However I believe it's better to choose unique locator that doesn't appear on the page twice.

I've developed additional perspective on this issue - I have DNS settings in my hosts file that are what resolve the visits to localhost, but also preserve the subdomain in the request (this latter point is important because Rails path helpers care which subdomain is being requested) To sum up the scope of the problem as it stands now - I need a way within Heroku/Capybara system tests to both route requests to localhost, but also maintain the subdomain information of the request. I've been able to accomplish one or the other, but haven't found a configuration that provides both yet.

session = ActionDispatch::Integration::Session.new(Rails.application) response = session.post("/mypath", my_params: "go_here")

As has been stated elsewhere, in a Capybara test you typically want to do POSTs by submitting a form just like the user would.

I used the above to test what happens to the user if a POST happens in another session (via WebSockets), so a form wouldn't cut it.

You can pass any options to puma via the server setting Capybara.server = :puma, { queue_requests: true }

Capybara can get us part of the way there. It allows us to work with an API rather than manipulating the HTML directly, but what it provides isn't an application specific API. It gives us low-level API methods like find, fill_in, and click_button, but it doesn't provide us with high-level methods to do things like "sign in to the app" or "click the Dashboard item in the navigation bar".

If you're looking for a slightly higher level API built on the same technology, you may want to check out watir or capybara.

If and when you need some kind of behaviour that waits for things, wait_until is a giant big sledgehammer. There are more fine grained, sophisticated tools built into Capybara, and I want you to learn about them, because those are some of the best features of the library. And when the built in tools aren’t enough, there are more sophisticated tools available than that clunky hammer. So hopefully the removal of wait_until encourages you to write better tests.

I am firmly convinced that asserting on the state of the interface is in every way superior to asserting on the state of your model objects in a full-stack test.

Even if #foo is originally on the page and then removed and replaced with a #foo which contains baz after a short wait, Capybara will still figure this out.

I have a rule that I won't allow Capybara to be monkey-patched in Poltergeist. This gives some indication to users about whether something is non-standard. So basically all non-standard stuff must be on page.driver rather than page (or a node).

What seems more problematic is divergence between drivers. For example, capybara-webkit and poltergeist support several of the same things. Let's take resizing the window as an example. In capybara-webkit this is page.driver.resize_window(x, y) and in poltergeist it's page.driver.resize(x, y). This means that if a user wants to switch from one to the other they have to change their code. Now I don't know if selenium does or doesn't support resizing the window, but supposing it doesn't I think there's still a lot of value in the capybara project deciding what the blessed API is, because then all the drivers that support that feature can implement it using the same API, increasing portability.

driven_by :selenium_chrome_headless

Rails.application.routes.default_url_options[:host] = "localhost:#{Capybara.current_session.server.port}"

That’s not the only way of writing end-to-end tests in Rails. For example, you can use Cypress JS framework and IDE. The only reason stopping me from trying this approach is the lack of multiple sessions support, which is required for testing real-time applications (i.e., those with AnyCable 😉).

Setting Capybara.server_port worked when the selenium integration test ran independent of other integration tests, but failed to change the port when run with other tests, at least in my env. Asking for the port number capybara wanted to use, seemed to work better with running multiple tests. Maybe it would have worked if I changed the port for all tests, instead of letting some choose on their own.

config.default_max_wait_time = ENV.has_key?("CI") ? 60 : 10

app_host is used whenever you call visit to generate the url, server_host sets the ip the server should accept connections from to use (0.0.0.0 means all network interfaces) and finally server_port sets the server port (auto generated by default).You are correct in that both app and server host should be set. Could you try server_host = “0.0.0.0” and app_host = “http://rails:#{Capybara.server_port}”.

The default fill_in method of Capybara is case sensitive. This is apparently due to their use of XPath. Anyhow, this seems to not be very well aligned with the entire idea of DSLs and letting non programmers write tests.

After some searching i found a stack overflow problem that didn't fix my issue but anyhow… I simply used a little ruby and the capybara library to find the field myself with some case insensitive regex and the ruby detect method

find_field finds by id, name or placeholder text - so find_field('Prefix') should find the element with matching placeholder text rather than needing xpath.

It might be possible to fix it in Capybara, but I'm afraid that we'd just add more unexpected, ambiguous behaviour (which key should have been pressed, backspace, space?).

find_field('Prefix').send_keys([:control, "a"], :backspace)

fill_in('Foo', with: 'bar', fill_options: { clear: :backspace })

why do you guys think have_css matcher is named the way it is? I mean, it sure deals with css identifiers, but have_css gives(at least to me) the impression that the page has certain stylesheet loading.

I have a feature spec to test the Javascript behavior of the blur event, sadly Capybara's native DSL doesn't seem to support it yet.

Just by looking at the page you can see that it's not a normal check box. You are hiding the checkbox via CSS (opacity: 0) and replacing it with an image for styling reasons. Since the checkbox isn't visible Capybara can't find it. There are a couple of ways to deal with this, either find the element that contains the image being used as a replacement for the checkbox and click on that, or tell check/uncheck that it's allowed to click on the label if necessary to switch the checkbox

Capybaras can run very fast with a top speed of about 22 mph (35 km an hour).  They can run as fast as a small horse.

. The distance from the main grazing areas to the nearest pond is never more than 300 m. Most mating takes place in water

Capybaras are very agile in water and can swim very fast. They can spend long hours in water, in part to thermoregulate (maintain a lower body temperature) as their sweat glands are not well developed. They can remain under water for up to 5 minutes.

A Jaguar has to be within 3 feet of a capybara to have a chance of a successful attack.