Skip to content

Instantly share code, notes, and snippets.

@jendiamond
Created July 18, 2019 22:52
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jendiamond/402f69a9ed9c5384dd7682819b9f3735 to your computer and use it in GitHub Desktop.
Save jendiamond/402f69a9ed9c5384dd7682819b9f3735 to your computer and use it in GitHub Desktop.

Don't lose faith in the reliability of your test suite

https://engineering.gusto.com/eliminating-flaky-ruby-tests/ It is human nature to ignore alarms when there is a history of false signals coming from a system.

Flaky Tests have a destructive effect on developer productivity

  • builds were needlessly retried,
  • trust in our test suite was eroded, and
  • frustration with our CI system grew among the team.
  • Non-deterministic tests led to slower iteration velocity because we couldn’t rely on our build results, and
  • fixes were prevented from being shipped in a timely manner

Unfortunately, Capybara has a variety of methods that do not wait for an element to show on the page, and the docs aren’t as explicit as we would like. Here is a list of methods we avoid when writing Capybara request specs:

Avoid dangerous methods that do not wait

visit(path) / current_path all(selector) / first(selector) Accessors: text, value, title, etc Use safe methods that do wait

find(selector), find_field, find_link has_selector?, has_no_selector? Actions: click_link, click_button, fill_in

If you use safe methods, Capybara will wait until the configured timeout (Capybara.default_max_wait_time) for the element to appear. Using these safe methods that do wait when asserting against the DOM will ensure tests are resilient to asynchronous actions in JavaScript code.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment