I'm very proud and pleased to finally release Capybara 2.0, many thanks to the many, many contributors who made this release possible.
First things first, this release is NOT BACKWARDS COMPATIBLE with Capybara 1.x in a few important ways. We've taken this opportunity to make a couple of changes which were long overdue and which hopefully will improve the experience of using Capybara. Upon upgrade though, you will likely find that your tests break. We understand that this is going to cause you frustration and lost time. We are not making these changes lightly, and there aren't likely to be any further changes for a long time after this. We are committed to a stable API.
That being said, here's what you need to watch out for.
When finding and interacting with elements through methods such as `click_link` and `fill_in`, if there were more than one element which matched, previously Capybara would try to guess which one you meant. From now on, Capybara will raise an exception instead. For example, if you have two fields named "Password" and "Password confirmation", then `fill_in "Password", :with => "test"` will raise an exception.
I wrote a blog post about some techniques we use at Elabs to mitigate this problem:
For those who use RSpec with Capybara, the `:type` metadata used by Capybara tests has been changed from `:request` to `:feature`. This was done to avoid confusion with Rails' built in integration tests. Make sure you are using at least version `2.12.0` of `rspec-rails` if you are on Rails, as it enables these changes. You will probably need to move your Capybara tests to `spec/features`, as well as including all modules you previously included in request spec in your feature specs instead.
Andy Lindeman from the RSpec team wrote a blog post, explaining this change in more detail:
Please note that it will probably take a little while for other drivers, like capybara-webkit and Poltergeist to be available for Capybara 2. For now, only the bundled Selenium and RackTest drivers will work.
I hope you like this release, if you have any problems, please let us know as soon as possible!
> I'm very proud and pleased to finally release Capybara 2.0, many thanks to the many, many contributors who made this release possible.
Great news! Congratulations Jonas and team!
> First things first, this release is NOT BACKWARDS COMPATIBLE with Capybara 1.x in a few important ways. We've taken this opportunity to make a couple of changes which were long overdue and which hopefully will improve the experience of using Capybara. Upon upgrade though, you will likely find that your tests break. We understand that this is going to cause you frustration and lost time. We are not making these changes lightly, and there aren't likely to be any further changes for a long time after this. We are committed to a stable API.
> That being said, here's what you need to watch out for.
> When finding and interacting with elements through methods such as `click_link` and `fill_in`, if there were more than one element which matched, previously Capybara would try to guess which one you meant. From now on, Capybara will raise an exception instead. For example, if you have two fields named "Password" and "Password confirmation", then `fill_in "Password", :with => "test"` will raise an exception.
I'm all for being more precise, and it's a very good idea to not guess which element Capybara should use. However, I'd really like to see an option to use the exact phrase passed in to the finder. Since I like precision so much, I would *never* use just "Password" when I really wanted "Password confirmation". Has this possibility ever been discussed?
> However, I'd really like to see an option to use the exact phrase passed
in to the finder. Since I like precision so much, I would *never* use just "Password" when I really wanted "Password confirmation". Has this possibility ever been discussed?
We've discussed it before, yes. I would like that kind of option too. It's tricky to implement it correctly though, especially for labels. Consider that select tags and textareas contain text which we would have to exclude somehow, not to mention comments, script tags, inline styles and all other kinds of shenanigans someone could conceivably put in there. It would also be cumbersome when the labels or links contain additional characters, such as an asterisk to indicate that a field is required. So since it would be very difficult to be strict in all cases, we chose instead to be loose in all cases, that way, at least it's consistent.
Quick feedback / question: has anything changed in handling remote
servers? We have a simple test suite that tests remote app. I've
quickly changed capybara version in Gemfile and now we get that:
https://gist.github.com/a1a5fe787dfc698e05ba After quick debugging, it seems that capybara doesn't pass full path
to the driver.
Piotr: I've confirmed the issue. It seems like this only manifests when
Capybara has not started a web server, but is instead running against a
remote app and visit is given a relative URL. In that case, Capybara
doesn't seem to add the app_host to the URL. It seems that this particular
combination isn't tested in our test suite. I will make sure to add tests
for it and push out a bug fix release as soon as possible.
Jonas, could you provide the correct link to the 51 simple tips? That link is going to admin and forcing login. Removing admin from the url results in a 404.
On Wednesday, November 14, 2012 5:28:59 AM UTC-5, jnicklas wrote:
> Hi everyone,
> I'm very proud and pleased to finally release Capybara 2.0, many thanks to > the many, many contributors who made this release possible.
> First things first, this release is NOT BACKWARDS COMPATIBLE with Capybara > 1.x in a few important ways. We've taken this opportunity to make a couple > of changes which were long overdue and which hopefully will improve the > experience of using Capybara. Upon upgrade though, you will likely find > that your tests break. We understand that this is going to cause you > frustration and lost time. We are not making these changes lightly, and > there aren't likely to be any further changes for a long time after this. > We are committed to a stable API.
> That being said, here's what you need to watch out for.
> When finding and interacting with elements through methods such as > `click_link` and `fill_in`, if there were more than one element which > matched, previously Capybara would try to guess which one you meant. From > now on, Capybara will raise an exception instead. For example, if you have > two fields named "Password" and "Password confirmation", then `fill_in > "Password", :with => "test"` will raise an exception.
> I wrote a blog post about some techniques we use at Elabs to mitigate this > problem:
> For those who use RSpec with Capybara, the `:type` metadata used by > Capybara tests has been changed from `:request` to `:feature`. This was > done to avoid confusion with Rails' built in integration tests. Make sure > you are using at least version `2.12.0` of `rspec-rails` if you are on > Rails, as it enables these changes. You will probably need to move your > Capybara tests to `spec/features`, as well as including all modules you > previously included in request spec in your feature specs instead.
> Andy Lindeman from the RSpec team wrote a blog post, explaining this > change in more detail:
> Please note that it will probably take a little while for other drivers, > like capybara-webkit and Poltergeist to be available for Capybara 2. For > now, only the bundled Selenium and RackTest drivers will work.
> I hope you like this release, if you have any problems, please let us know > as soon as possible!
On Wednesday, 14 November 2012 11:28:59 UTC+1, jnicklas wrote:
> Hi everyone,
> I'm very proud and pleased to finally release Capybara 2.0, many thanks to > the many, many contributors who made this release possible.
> First things first, this release is NOT BACKWARDS COMPATIBLE with Capybara > 1.x in a few important ways. We've taken this opportunity to make a couple > of changes which were long overdue and which hopefully will improve the > experience of using Capybara. Upon upgrade though, you will likely find > that your tests break. We understand that this is going to cause you > frustration and lost time. We are not making these changes lightly, and > there aren't likely to be any further changes for a long time after this. > We are committed to a stable API.
> That being said, here's what you need to watch out for.
> When finding and interacting with elements through methods such as > `click_link` and `fill_in`, if there were more than one element which > matched, previously Capybara would try to guess which one you meant. From > now on, Capybara will raise an exception instead. For example, if you have > two fields named "Password" and "Password confirmation", then `fill_in > "Password", :with => "test"` will raise an exception.
> I wrote a blog post about some techniques we use at Elabs to mitigate this > problem:
> For those who use RSpec with Capybara, the `:type` metadata used by > Capybara tests has been changed from `:request` to `:feature`. This was > done to avoid confusion with Rails' built in integration tests. Make sure > you are using at least version `2.12.0` of `rspec-rails` if you are on > Rails, as it enables these changes. You will probably need to move your > Capybara tests to `spec/features`, as well as including all modules you > previously included in request spec in your feature specs instead.
> Andy Lindeman from the RSpec team wrote a blog post, explaining this > change in more detail:
> Please note that it will probably take a little while for other drivers, > like capybara-webkit and Poltergeist to be available for Capybara 2. For > now, only the bundled Selenium and RackTest drivers will work.
> I hope you like this release, if you have any problems, please let us know > as soon as possible!
> On Wednesday, 14 November 2012 11:28:59 UTC+1, jnicklas wrote:
>> Hi everyone,
>> I'm very proud and pleased to finally release Capybara 2.0, many thanks
>> to the many, many contributors who made this release possible.
>> First things first, this release is NOT BACKWARDS COMPATIBLE with
>> Capybara 1.x in a few important ways. We've taken this opportunity to make
>> a couple of changes which were long overdue and which hopefully will
>> improve the experience of using Capybara. Upon upgrade though, you will
>> likely find that your tests break. We understand that this is going to
>> cause you frustration and lost time. We are not making these changes
>> lightly, and there aren't likely to be any further changes for a long time
>> after this. We are committed to a stable API.
>> That being said, here's what you need to watch out for.
>> When finding and interacting with elements through methods such as
>> `click_link` and `fill_in`, if there were more than one element which
>> matched, previously Capybara would try to guess which one you meant. From
>> now on, Capybara will raise an exception instead. For example, if you have
>> two fields named "Password" and "Password confirmation", then `fill_in
>> "Password", :with => "test"` will raise an exception.
>> I wrote a blog post about some techniques we use at Elabs to mitigate
>> this problem:
>> For those who use RSpec with Capybara, the `:type` metadata used by
>> Capybara tests has been changed from `:request` to `:feature`. This was
>> done to avoid confusion with Rails' built in integration tests. Make sure
>> you are using at least version `2.12.0` of `rspec-rails` if you are on
>> Rails, as it enables these changes. You will probably need to move your
>> Capybara tests to `spec/features`, as well as including all modules you
>> previously included in request spec in your feature specs instead.
>> Andy Lindeman from the RSpec team wrote a blog post, explaining this
>> change in more detail:
>> Please note that it will probably take a little while for other drivers,
>> like capybara-webkit and Poltergeist to be available for Capybara 2. For
>> now, only the bundled Selenium and RackTest drivers will work.
>> I hope you like this release, if you have any problems, please let us
>> know as soon as possible!
Congratulations on the release, and thank you for your work on this!
Regarding the Password vs Password confirmation field, what is the best way to handle this? You mention using "within" on the blog post but the password field may not be within a separate element than the password confirmation. Would using the id of the field work?
fill_in 'user_password', with: 'secret'
Or will that also catch the user_password_confirmation id?
Ryan: Using the id would indeed work, since matches on `id` and `name` need to be exact, and are not allowed to be substrings. If you don't want to use ids, there are two sensible alternatives, you could change the labels to be less ambiguous, ("Enter password", "Confirm password", maybe?), or you could do something like: `all(:field, "Password").each { |field| field.set("value") }`. If you encapsulate that in some kind of method, it could actually looks somewhat decent `fill_in_all "Password", :with => "value"`, or something.
Maybe I am reading it wrong, but are you saying that on a page with password and password confirmation, "click_link "Password" will fail? I would have thought it correct that this click password as it matches exactly, and requires click_link "password confirmation" for the other one for disambiguation? Perhaps I am reading this wrong and being incredibly stupid (more likely ;)
On Wednesday, 14 November 2012 10:28:59 UTC, jnicklas wrote:
> Hi everyone,
> I'm very proud and pleased to finally release Capybara 2.0, many thanks to > the many, many contributors who made this release possible.
> First things first, this release is NOT BACKWARDS COMPATIBLE with Capybara > 1.x in a few important ways. We've taken this opportunity to make a couple > of changes which were long overdue and which hopefully will improve the > experience of using Capybara. Upon upgrade though, you will likely find > that your tests break. We understand that this is going to cause you > frustration and lost time. We are not making these changes lightly, and > there aren't likely to be any further changes for a long time after this. > We are committed to a stable API.
> That being said, here's what you need to watch out for.
> When finding and interacting with elements through methods such as > `click_link` and `fill_in`, if there were more than one element which > matched, previously Capybara would try to guess which one you meant. From > now on, Capybara will raise an exception instead. For example, if you have > two fields named "Password" and "Password confirmation", then `fill_in > "Password", :with => "test"` will raise an exception.
> I wrote a blog post about some techniques we use at Elabs to mitigate this > problem:
> For those who use RSpec with Capybara, the `:type` metadata used by > Capybara tests has been changed from `:request` to `:feature`. This was > done to avoid confusion with Rails' built in integration tests. Make sure > you are using at least version `2.12.0` of `rspec-rails` if you are on > Rails, as it enables these changes. You will probably need to move your > Capybara tests to `spec/features`, as well as including all modules you > previously included in request spec in your feature specs instead.
> Andy Lindeman from the RSpec team wrote a blog post, explaining this > change in more detail:
> Please note that it will probably take a little while for other drivers, > like capybara-webkit and Poltergeist to be available for Capybara 2. For > now, only the bundled Selenium and RackTest drivers will work.
> I hope you like this release, if you have any problems, please let us know > as soon as possible!
