

Capybara: Acceptance test framework for web applications - sachalep
https://github.com/jnicklas/capybara

======
mtsmith85
Capybara has been a part of my/our workflow for a while; I'm curious why this
is on the frontpage -- is there a specific update I'm missing?

Either way, I really enjoy Capybara -- especially being able to jump between
different drivers for various reasons.

~~~
briandear
Yeah, it feels like we're partying like it's 2011. I have no idea why this is
one the front page either.

------
thibaut_barrere
If you use Capybara, a couple of useful notes, based on what I learned
implementing js-enabled &headless specs for my SaaS [3]:

First, using the poltergeist driver [1] which is PhantomJS based will tend to
be faster AND raise errors when a javascript error occurs (unlike capybara-
webkit), which is really handy if your app has a bit of javascript.

Also, you can inject puffing-billy [2] into the mix: this is a proxy that will
allow you to mock XHR queries without touching the javascript libraries. This
allows to write full integration specs for scenarios involving libraries like
Stripe/Recurly.js etc, but using mocked calls.

[1]
[https://github.com/teampoltergeist/poltergeist](https://github.com/teampoltergeist/poltergeist)

[2] [https://github.com/oesmith/puffing-
billy](https://github.com/oesmith/puffing-billy)

[3] [https://www.wisecashhq.com](https://www.wisecashhq.com)

~~~
dankohn1
I recommend using the built-in Rack Test for tests that don't require
Javascript, and Poltergeist for tests that do. That is the fastest
configuration.

~~~
packersville
Very good point. I do this when I can so my suit runs much faster.

------
tonyhb
Capybara's a great too that we use heavily at
[https://www.incoin.io](https://www.incoin.io). One of the hangups we had is
with multiple API endpoints being hit for a particular page. In some instances
the first API request would finish and Capybara would assume that loading is
done, when really there's another API request pending meaning our promises
haven't yet finished and tests would fail randomly.

In order to prevent this you need to delay Capybara's processing so that all
requests have finished using a request counter. Information is here:
[http://tonyhb.com/stop-treading-water-with-marionette-and-
ca...](http://tonyhb.com/stop-treading-water-with-marionette-and-capybara)

Other than that, Capybara is absolutely amazing. It doesn't replace manual UI
testing by any means, though it provides a lot of confidence knowing we
haven't broken critical components of our app.

------
CSDude
If you liked this, you might also like the following:
[https://github.com/webdriverio/cucumber-
boilerplate](https://github.com/webdriverio/cucumber-boilerplate) , not as
detailed as Capybara but similar

------
lectrick
I think that your ultimate goal is to rely on Capybara for your testing as
little as cleverly possible. Push all your logic into separately-unit-testable
JS, perhaps use a DOM emulator, anything to get away from slow, barely-
deterministic full browser Capybara testing.

------
gcb0
so, yet another later on top of seleniun or I'm missing something?

~~~
eloisius
Selenium is one of the many drivers it can use. This is a DSL for driving a
browser.

~~~
thibaut_barrere
Indeed, it also works with webkit (capybara-webkit) and phantomjs (poltergeist
driver) too.

------
ascotan
I was disappointed that the subtitle wasn't "tighter and tighter testing".
[http://i.imgur.com/1aD54YR.jpg](http://i.imgur.com/1aD54YR.jpg)

