Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Never sleep() using Capybara!
# WAIT! Do consider that `wait` may not be needed. This article describes
# that reasoning. Please read it and make informed decisions.
# https://www.varvet.com/blog/why-wait_until-was-removed-from-capybara/
# Have you ever had to sleep() in Capybara-WebKit to wait for AJAX and/or CSS animations?
describe 'Modal' do
should 'display login errors' do
visit root_path
click_link 'My HomeMarks'
within '#login_area' do
fill_in 'email', with: 'will@not.work'
fill_in 'password', with: 'test'
click_button 'Login'
end
# DO NOT sleep(1) HERE!
assert_modal_visible
page.find(modal_wrapper_id).text.must_match %r{login failed.*use the forgot password}i
end
end
# Avoid it by using Capybara's #wait_until method. My modal visible/hidden helpers
# do just that. The #wait_until uses the default timeout value.
def modal_wrapper_id
'#hmarks_modal_sheet_wrap'
end
def assert_modal_visible
wait_until { page.find(modal_wrapper_id).visible? }
rescue Capybara::TimeoutError
flunk 'Expected modal to be visible.'
end
def assert_modal_hidden
wait_until { !page.find(modal_wrapper_id).visible? }
rescue Capybara::TimeoutError
flunk 'Expected modal to be hidden.'
end
# Examples of waiting for a page loading to show and hide in jQuery Mobile.
def wait_for_loading
wait_until { page.find('html')[:class].include?('ui-loading') }
rescue Capybara::TimeoutError
flunk "Failed at waiting for loading to appear."
end
def wait_for_loaded
wait_until { !page.find('html')[:class].include?('ui-loading') }
rescue Capybara::TimeoutError
flunk "Failed at waiting for loading to complete."
end
def wait_for_page_load
wait_for_loading && wait_for_loaded
end
@olkeene

This comment has been minimized.

Copy link

commented Aug 26, 2011

The same trick should be used for ajax content

@DCarper

This comment has been minimized.

Copy link

commented Aug 26, 2011

That's pretty cool I #sleep all the time!

edited because my question was besides the point :) thanks for the tip

@szajbus

This comment has been minimized.

Copy link

commented Aug 26, 2011

Actually Capybara has this feature built-in. See Capybara.default_wait_time option.

And this is not going to work if you want to test element that is already visible on the page, but should be reloaded after clicking AJAX link.

I blogged about this in detail recently at http://codetunes.com/2011/08/20/testing-ajax-reloaded-elements-with-capybara

@metaskills

This comment has been minimized.

Copy link
Owner Author

commented Aug 26, 2011

@DCarper Yea, by itself, a find will wait until it show up or times out.

@szajbus Good point, I had that set already in my app. Great link too!

@jrafanie

This comment has been minimized.

Copy link

commented Aug 26, 2011

@metaskills Great example!
@szajbus Along those lines, we have select boxes whose contents are dynamically updated when clicking/selecting something. I run into the same issue where the select element is already loaded but its contents are not yet updated. With this known, you can use the same wait_until to check for the updated contents of the select instead of just sleeping, which is both faster and less error-prone.

@metaskills

This comment has been minimized.

Copy link
Owner Author

commented Aug 27, 2011

I updated visible/hidden assertion helpers to rescue the Capybara::TimeoutError and flunk with a message. I found that when the timeout happens, this is a much better way to fail the test.

@metaskills

This comment has been minimized.

Copy link
Owner Author

commented Sep 21, 2011

I added examples of "waiting for a page loading to show and hide in jQuery Mobile" to the gist.

@endymion

This comment has been minimized.

Copy link

commented Mar 9, 2012

I forked this to add a method that I came up with today for waiting for jQuery Mobile page transitions to complete:

https://gist.github.com/2007777

@dball

This comment has been minimized.

Copy link

commented Apr 6, 2012

If using jQuery, there turns out to be a modestly more elegant solution:

wait_until { 
  page.evaluate_script('jQuery.active') == 0
}

Apparently this becomes jQuery.ajax.active in a forthcoming release of jQuery. Since it uses an internal jQuery counter that isn't explicitly part of the API, that's par for the course, but it works without regard to DOM structure or the success of a DOM surgery.

@metaskills

This comment has been minimized.

Copy link
Owner Author

commented Apr 6, 2012

Well that is fine for AJAX requests but I have found that waiting for AJAX requests is a small part of writing good async tests. I think the focus should be on the DOM, especially in regards to animations and transitions. Thankfully, capybara already does this in many ways automatically and in some cases the rspec matches it provides even goes one step further. I have seen way to many capybara-webkit bugs/failures that are in fractions of a second while the DOM is in transition. Less so due to AJAX requests.

@polarblau

This comment has been minimized.

Copy link

commented Apr 24, 2012

A variation:

it 'lets the user login', :js => true do
  wait_until_scope_exists '#login-form' do
    fill_in 'Email', :with => 'foo@bar.com' 
    fill_in 'Password', :with => 'secret'
    click_on 'Sign in'
  end
  page.should have_content('Welcome!')
end

# ...

def wait_until_scope_exists(scope, &block)
  wait_until { page.has_css?(scope) }
  within scope, &block
rescue Capybara::TimeoutError
  flunk "Expected '#{scope}' to be present."
end
@megabga

This comment has been minimized.

Copy link

commented Sep 20, 2012

Thanks, its what a looking for, works like a charm!

@nathanbain

This comment has been minimized.

Copy link

commented Nov 8, 2012

Be aware that #wait_until has been removed from Capybara 2.0.
Read the notes here: https://groups.google.com/forum/?fromgroups=#!topic/ruby-capybara/qQYWpQb9FzY

@killthekitten

This comment has been minimized.

@NewAlexandria

This comment has been minimized.

Copy link

commented Jan 9, 2015

Yes, has_content and has_css is the contemporary practice — letting capybara configs decide, abstract, and dry-up the configs

@Brantron

This comment has been minimized.

Copy link

commented Apr 10, 2016

Just found this while researching modal issues LOL

@dpulliam

This comment has been minimized.

Copy link

commented Jul 25, 2016

Lol, brandon, i just stumbled on this too! Great stuff ken :)

@Kufert

This comment has been minimized.

Copy link

commented Jun 29, 2017

I have an issue where a plugin I use adds the click event after 200ms, so w/o the sleep the click dose nothing. I can't wait for html/css, as all of that is already on the screen. Is there a way to wait for the click event to be added or am I doomed to use sleep?

@kevinhq

This comment has been minimized.

Copy link

commented Nov 1, 2018

wait_until is removed from capybara now?

@KamilBehnke

This comment has been minimized.

Copy link

commented Nov 8, 2018

@kevinhq yes, it is removed from capybara

@vmarquet

This comment has been minimized.

@heridev

This comment has been minimized.

Copy link

commented May 11, 2019

For that scenario when maybe the loading spinner is blocking the ui and you need to force sleep in a smarter way, what about?

      while page.has_css?('.pageLoader')
        puts "waiting"
        sleep 0.1
      end
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.