CODEWITHSUNDEEP
javascriptrubyseleniumautomationcapybara
chasethesunnn
chasethesunnn

Reputation: 2234

Browser is done loading and capybara still failing test

I am running automation that checks document.readyState === 'complete' and also a local variable called window.renderComplete (for when the server is done with rendering the page).

But somehow the Capybara.current_session.driver.browser.title is failing a title == Capybara.current_session.driver.browser.title for a few loops of that check. It probably loops 10 times before the check passes and it breaks the loop.

Is there a time period after the browser gets all the data that it takes to set the data into certain variables? Or is this a capybara flaw? I can't really pinpoint why there would still be a delay in the browser, if readyState and renderComplete are both true.

renderComplete = page.evaluate_script("(window.renderComplete == true) && (document.readyState === 'complete');")

      if renderComplete
        puts "pass 1"
      else
        loop do
          renderComplete = page.evaluate_script("window.renderComplete == true;")
          break if renderComplete == true
        end
        puts "pass 2"
      end

browser = Capybara.current_session.driver.browser
Timeout::timeout(Capybara.default_max_wait_time) do
    i=1
    loop do
      puts "loop! #{i}"
      i+=1
      break if title == browser.title
    end
  end
assert_equal title, browser.title

Upvotes: 0

Views: 119

Answers (1)

Thomas Walpole
Thomas Walpole

Reputation: 49890

You shouldn't be doing equal assertions against title, nor using driver specific methods (anytime you do current_session.driver.xxx you're probably doing something wrong. To verify a pages title is what you expect just use one of the title assertion/matcher methods provided by Capybara (which will also include the builtin waiting/retrying)

page.assert_title(expected_title)

Also, note that using Timeout::timeout with code that's talking to network clients is highly dangerous since it can interrupt code at any point and leave those communications in a non-recoverable state. If you need to use some sort of timeout with Capybara you're much better off just sleeping in a loop and checking the condition until the expected time has passed than using Timeout::timeout - see http://www.mikeperham.com/2015/05/08/timeout-rubys-most-dangerous-api/

Upvotes: 1

Related Questions