corner_stones should run with capybara version 2.

[tonini]

Hi,

I updated corner_stones to run with capybara ~> 2.1.0.

Adjustment:

• Remove wait_unit, it's not available anymore in version 2. more details
• Capybara::Timeout not available anymore. see the ActiveTracking#assert_current_tab_is how the ActiveTabMismatchError raise is now handled. Please give some feedback if you have better solution.
• update .travis.yml to also test under ruby

Cheers

[senny]

as the changes are very minor, would is it still possible to use Capybara 1.x with your changes? Maybe we could then specify a more loose dependency on Capybara and support both...

[tonini]

The thing is wait_until are completely removed by capybara 2 because capybara's auto-waiting are much more mature now. We would have to implement our own wait_until:

def wait_until
  require "timeout"
  Timeout.timeout(Capybara.default_wait_time) do
    sleep(0.1) until value = yield
    value
  end
end

Further we have to check if the Capybara::Timeout is defined, otherwise create our own.

My opinion is that It could made, but I wouldn't do it. Maybe we should ppl give a poke in the capybara 2.0 direction. ;)

[senny]

are you sure that the finders did not have an internal waiting period before 2.0? From the blog post you referenced:

Capybara has a had a very important feature since pretty much the beginning which is that it automatically waits for elements to appear or disappear on the page. If you do something like find("#foo"), this will block until an element with id “foo” appears on the page

Can you verify if that is in fact the case and the previous code was just a unnecessary duplication?

[tonini]

Ok I tested it locally:

With capybara 1.1.4 the following same code adjustments works and tests are pass:

def assert_current_tab_is(tab)
  current_tab = nil
  current_tab = find(@element_scope).find('.active').text
  current_tab == tab || raise
rescue
  raise ActiveTabMismatchError, "the active tab is '#{current_tab}' instead of '#{tab}'"
end

You're right they had a internal waiting period before 2.0.

As long as you stick to the Capybara API, and have a basic grasp of how its waiting behaviour works, you should never have to use wait_until explicitly.

[senny]

@tonini thanks, let's loosen up the version dependency then.

[tonini]

@senny Ok I did the update, is it ok this way?

[senny]

I think we should be fine with removing the version specification completely.

[tonini]

done! :green_apple:

[senny]

@bjoernbur As you are still using Capybara 1.x can you test your test-suite agains this PR and let me know if everything still works?

[bjoernbur]

@senny I'll try this. The problem is, that we use a dedicated revision (590bfeb9db7f660c7c9eb2c9d2f9f28265c58fc0). So I think that the result will not be significant. Or I have to upgrade to the latest version.

[senny]

@bjoernbur I remember there is still the issue regarding the new table API... If you can test something out that would ge great otherwise I'm going to merge this one.

[bjoernbur]

@senny I tried it and get quiet a lot of exceptions. So I would have to upgrade to the latest version of corner_stones first, fix the open issues und then I would be able to give you more information.

[senny]

@bjoernbur let me know if you can upgrade and if there are problems. In the meantime I'm going to merge this one.

@tonini the CI is failing, can you take a look: https://travis-ci.org/senny/corner_stones/jobs/8044443

[tonini]

@senny capybara has drop the ruby 1.9.2 support : s.required_ruby_version = ">= 1.9.3" Looks like this is the problem?

Should I update the travis setup?

[bjoernbur]

@senny I'll try to make the upgrade this week. But not sure if I'll have enough time.

[senny]

@tonini sure, no need to support 1.9.2 anymore.

[tonini]

@senny all green :green_heart:

[senny]

awesome thanks! :heart:

[tonini]

My pleasure!