[ANN] Capybara 2.0.0

Showing 1-16 of 16 messages
[ANN] Capybara 2.0.0 jnicklas 11/14/12 2:28 AM
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: 


This release also drops official support for Ruby 1.8.x.

There are a few other major changes, which might affect you. Make sure to review the changes listed in the History file:


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!

/Jonas
Re: [Capybara] [ANN] Capybara 2.0.0 Phillip Koebbe 11/14/12 3:40 AM

On Nov 14, 2012, at 4:28 AM, 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.
>

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?

Phillip
Re: [Capybara] [ANN] Capybara 2.0.0 jnicklas 11/14/12 3:50 AM
> 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.

/Jonas
unk...@googlegroups.com 11/14/12 4:20 AM <This message has been deleted.>
Re: [ANN] Capybara 2.0.0 pietia 11/14/12 4:20 AM
Hi !

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.
Re: [Capybara] [ANN] Capybara 2.0.0 jnicklas 11/14/12 5:01 AM
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.
Re: [ANN] Capybara 2.0.0 Steve Tipton 11/14/12 6:11 AM
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.

Thanks!
Re: [ANN] Capybara 2.0.0 Kosmas Chatzimichalis 11/14/12 6:20 AM
Nice Jonas,

There is a mistake with one of your links though




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: 


This release also drops official support for Ruby 1.8.x.

There are a few other major changes, which might affect you. Make sure to review the changes listed in the History file:


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!

/Jonas
Re: [Capybara] Re: [ANN] Capybara 2.0.0 jnicklas 11/14/12 7:17 AM
Damn it, I always do that. Need to remember to check all links in an incognito session.
Re: [Capybara] Re: [ANN] Capybara 2.0.0 jnicklas 11/14/12 7:49 AM
This is the correct link to the blog post: http://www.elabs.se/blog/51-simple-tricks-to-clean-up-your-capybara-tests
Re: [Capybara] Re: [ANN] Capybara 2.0.0 Ryan Bates 11/14/12 10:11 AM
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


On Wednesday, November 14, 2012 7:49:52 AM UTC-8, jnicklas wrote:
This is the correct link to the blog post: http://www.elabs.se/blog/51-simple-tricks-to-clean-up-your-capybara-tests
Re: [Capybara] Re: [ANN] Capybara 2.0.0 jnicklas 11/14/12 11:41 AM
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.

/Jonas
Re: [ANN] Capybara 2.0.0 Kevin McCaughey 11/20/12 10:50 AM
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 ;)
Re: [Capybara] Re: [ANN] Capybara 2.0.0 jnicklas 11/20/12 10:57 AM
Kevin: no, you are quite correct, see my reply to Ryan, above.
Re: [ANN] Capybara 2.0.0 sushma B 11/27/12 5:34 AM
Hi All,

I am trying to do below operation with sending text with open and close braces as below but capybara escapes "(" always.



Input : fill_in('edit-field-bbcgf-ingredients-und-1-target-id', :with => "2-3 garlic cloves, peeled and chopped (4637)")

I have tried with below combination. But non of the option seems working

1. "2-3 garlic cloves, peeled and chopped \(4637)"
2. '2-3 garlic cloves, peeled and chopped (4637)'

Output: "2-3 garlic cloves, peeled and chopped 4637)"

Any solution for this issue? Please share

Regards,
Sushma
Re: [Capybara] Re: [ANN] Capybara 2.0.0 Siva JANKAN 11/27/12 7:43 AM
Did you try html safe replace for "("  .
Please refer: http://www.ascii.cl/htmlcodes.htm


Siva--
------------------------------------------
Sivakumar P Kandasamy,

Software Engineer
M2S (www.m2s.com)
------------------------------------------