GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Turns out, this was a generally bad thing and can cause all sorts of really funky issues when used for actual Scenarios instead of stupid mocked out ones in RSpec.
Instead of retrying the entire Scenario, we'll just be opinionated and make sure that Capybara will catch and retry individual actions if a Selenium::WebDriver::Errors::UnknownError occurs
Starting work on this now.
(This message brought to you by Hub board)
Add the beginnings of a fully wrapped and retryable Capybara driver
In theory this should help with #67, but it's terribly painful to unit test
and I'm not sure I'll really know if this is working until I put it into production :-/
Add actual retry logic to #handle_retry
This will make #67 actually work, presuming the #base_find actually works
I have to agree at this point. I prefer the gem to handle command retries as much as possible rather than full test retries. There's some situations where this won't be doable (like full Selenium halts), but for a lot of cases, retrying commands will be enough.
Stub out the remainder of the Capybara::Driver::Base API that will li…
…kely access Selenium
This might not be the comprehensive list, but it covers the APIs that are
covered by the Capybara::Driver::Selenium class
I think I have something working in my topic branch, which I will pull in after I do some testing with the changes combined with the Lookout Cucumber scenarios.
Interestingly enough, with my Capybara retry changes, it appears that the Sauce::Capybara::Driver class isn't passing off commands to the Sauce::Selenium2 object, but somehow is starting up "real" (i.e. local) Selenium code.