Introducing Capybara, an (early stage) alternative to webrat

[jnicklas]

Webrat is fantastic, and it has done wonders for testing Ruby webapps,
it provides a very slick and elegant DSL for interacting with webapps,
but it also has a couple of problems:

* It is strongly tied to Rails and the Integration Testing built into
Rails
* It doesn't have (comprehensive) support for testing JavaScript
* It is difficult to extend
* There is no driver agnostic test suite to make sure that Selenium
mode for example behaves the same as Rails mode.
* It cannot run different drivers in the same process, so it can't run
one feature under selenium and another in simulation.

All of these pain points led me to tinker around with building a
driver agnostic solution with the following goals:

* Make it dead simple to switch between different drivers
* Support multiple drivers out of the Box
* Provide a comprehensive test suite which can run against any driver
* Make it work with any Rack based framework
* Make it as compatible as possible with the Webrat API

The result of this work is called Capybara and can be found at GitHub
here: http://github.com/jnicklas/capybara

It uses rack-test to simulate a browser instead of Rails' Integration
Testing, which means that interacting with the controller is out (it's
bad practice anyway, imho. It's an integration test after all). I also
intentionally didn't make have_tag and have_text work, since those by
virtue of how they work will never be useful with Selenium, Culerity
or any other browser simulator. Instead there's have_content,
have_xpath and have_css. Other than that it's very similar to Webrat.

I recently managed to convert a fairly large cucumber suite which
previously used Webrat to use Capybara, and it seems to work rather
well.

What do you guys think, am I on the right track or is this an insane
idea?

/Jonas Nicklas

[aslak hellesoy]

I have only taken a quick peak, and the code looks a lot simpler than Webrat.
I'll have to give it a whirl before I give an opinion, but I have to
say it sounds really promising.

We're planning on moving webrat_steps.rb into
http://github.com/aslakhellesoy/cucumber-web and make them agnostic of
underlying backend - with implementations for webrat, webdriver etc.
supporting Capybara would of course be nice too. See thread a couple
of days back for details.

Aslak

> /Jonas Nicklas
>
> --
>
> You received this message because you are subscribed to the Google Groups "Cukes" group.
> To post to this group, send email to cu...@googlegroups.com.
> To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cukes?hl=.
>
>
>

[Jeroen van Dijk]

I'm looking forward to the result! And I will try it when I have the opportunity.

If I may add one thing that has bothered me when using Webrat. Webrat's relies on Nokogiri which supports css3 selectors. I think it would be great if  your library would rely on a html parser that is completely compatible with the jQuery css selector syntax. This makes your selectors completely testable in the browser, but more importantly it wouldn't matter what tool you are using as long as it supports jQuery (or its syntax). For me the (jQuery) css syntax makes a lot more sense than the xpath syntax, especially since I'm used to this syntax already in javascript and css. Another advantage of the jQuery selectors to the css3 selectors, those that are supported by Nokogiri, is that they are more powerful (See e.g. this problem I had http://groups.google.com.au/group/formtastic/msg/2601ac08d8c48a96).

So in summary, I think it would be a good idea to let your library rely on a html parser that supports the jquery selector syntax. Do you agree?

(I have looked shortly into extending Nokogiri and it looks possible, but I'm not sure how hard it would be)

Jeroen

[Joseph Wilk]

+1

There is a plugin for selenium that lets you feel the love of jQuery
selectors. I've always wanted to use the same style for Webrat.
http://github.com/caifara/rsquery

--
Joseph Wilk
http://blog.josephwilk.net
+44 (0)781281643

[Jonas Nicklas]

The only places where you'd be enetering selectors directly in
Capybara right now is with the 'within' and 'have_xpath/have_css'
methods. Within, can use CSS like this:

within :css, "#foo .bar[rel='blah']" do
end

It supports all the CSS selectors that Nokogiri can convert to XPath
(since everything uses XPath under the hood). Nokogiri looks to have
pretty comprehensive support for CSS3 selectors, I threw some pretty
advanced selectors at it and it seems to work nicely. For example, it
readily converts this rather advanced (and useless) selector:

#foo > li[contains("blah")][title^="bar"]:last-child ~ .baz

Into this XPath:

["//*[@id = 'foo']/*[contains(concat(' ', @class, ' '), ' baz
')][preceding-sibling::li[contains(., \"blah\") and
starts-with(@title, \"bar\") and last-child(.)]]"]

jQuery has some non-standard extensions to CSS, which this might not
support, but adding support for those is really out of the scope of
this project.

/Jonas

[Jeroen van Dijk]

On Fri, Nov 20, 2009 at 11:10 AM, Jonas Nicklas <jonas....@gmail.com> wrote:

The only places where you'd be enetering selectors directly in
Capybara right now is with the 'within' and 'have_xpath/have_css'
methods. Within, can use CSS like this:

   within :css, "#foo .bar[rel='blah']" do
   end

It supports all the CSS selectors that Nokogiri can convert to XPath
(since everything uses XPath under the hood). Nokogiri looks to have
pretty comprehensive support for CSS3 selectors, I threw some pretty
advanced selectors at it and it seems to work nicely. For example, it
readily converts this rather advanced (and useless) selector:

   #foo > li[contains("blah")][title^="bar"]:last-child ~ .baz

Actually, I didn't know about 'contains'
 

Into this XPath:

    ["//*[@id = 'foo']/*[contains(concat(' ', @class, ' '), ' baz
')][preceding-sibling::li[contains(., \"blah\") and
starts-with(@title, \"bar\") and last-child(.)]]"]

jQuery has some non-standard extensions to CSS, which this might not
support, but adding support for those is really out of the scope of
this project.

It is definitely out of the scope of your project, but it would be nice though. Sorry for the distraction.

Anyway, I have created a ticket for nokogiri:
http://github.com/tenderlove/nokogiri/issues#issue/172

Those who favor this feature might want to vote on it to get it under the attention :-)

Jeroen

 

/Jonas

[Wincent Colaiuta]

On 19 nov, 23:43, jnicklas <jonas.nick...@gmail.com> wrote:
> All of these pain points led me to tinker around with building a
> driver agnostic solution with the following goals:
>
> * Make it dead simple to switch between different drivers
> * Support multiple drivers out of the Box
> * Provide a comprehensive test suite which can run against any driver
> * Make it work with any Rack based framework
> * Make it as compatible as possible with the Webrat API
>
> The result of this work is called Capybara and can be found at GitHub
> here:http://github.com/jnicklas/capybara

If this thing actually does what the README says it does then it looks
pretty nice. Looking forward to trying it out.

Cheers,
Wincent

[Wincent Colaiuta]

Replying to my own post here for the benefit of anyone that might
stumble across this thread:

I've been trying out Capybara for a few days now and it pretty much
lives up to what the README claims for it. Moving my existing Cucumber
+ Webrat and Cucumber + Webrat + Selenium features was fairly
straightfoward, and it is a true joy to change one setting and watch
the exact same features run under Celerity/Culerity without any
tweaks.

It's labelled as "alpha" quality, but the code is very nice and clean,
and I've not really had any troubles with it so far. I'd strongly
encourage people to try it out and get behind the project. Would be
great to see it succeed.

Cheers,
Wincent

[Jonas Nicklas]

Thanks for the kind words. I consider it "Alpha" more in the sense of
being untested, rather than being broken. The test suite is
comprehensive and stable enough that I'm pretty sure that what's
covered actually works, but there might be unforeseen edge cases or
things that I missed, which can really only be revealed by actually
being used.

I've created a google group for Capybara, btw. It's at:

http://groups.google.com/group/ruby-capybara

/Jonas