51 Matching Annotations
  1. Nov 2023
  2. Sep 2023
    1. # 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
  3. Aug 2023
    1. 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).
  4. Feb 2023
    1. 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.
  5. Jan 2023
    1. 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.
  6. Nov 2022
    1. 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.
  7. Oct 2022
  8. Aug 2022
  9. Mar 2022
    1. 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".
  10. Nov 2021
    1. 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.
    2. 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.
    3. 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.
  11. Aug 2021
    1. 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).
    2. 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.
  12. Jun 2021
    1. 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 😉).
    1. 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.
    1. 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}”.

      app_host ~ server_host

  13. Apr 2021
    1. 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.

      not very well aligned

    2. 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
    1. fill_in('Foo', with: 'bar', fill_options: { clear: :backspace })

      first sighting: fill_options: { clear: :backspace })

      first sighting: fill_options as an option at all (for fill_in only, I presume)

      I wonder they added at all as a response to this:

      See also: https://hyp.is/ZcXVJJMyEeucgmPXYFP9yg/github.com/teamcapybara/capybara/issues/203

      (which key should have been pressed, backspace, space?)

    1. 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.
  14. Oct 2020
  15. Nov 2019
  16. Oct 2019
  17. Sep 2019
  18. Aug 2019
    1. 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
  19. Dec 2018
    1. 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.
    2. . The distance from the main grazing areas to the nearest pond is never more than 300 m. Most mating takes place in water
    3. 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.
    4. A Jaguar has to be within 3 feet of a capybara to have a chance of a successful attack.
  20. Jan 2016
    1. Jeff Atwood tweeted a picture of someone's pet capybara, and a reply led me to this page. They are not suitable as pets -- unless you are willing to be a full time caretaker.