5 ms·
Capybara: Acceptance test framework for web applications
- gcb0 11y agoso, yet another later on top of seleniun or I'm missing something?
- jakenberg 11y agoI think you're missing a "y" ;)
- gcb0 11y agoah yes, typo. t->y
- eloisius 11y agoSelenium is one of the many drivers it can use. This is a DSL for driving a browser.
- thibaut_barrere 11y agoIndeed, it also works with webkit (capybara-webkit) and phantomjs (poltergeist driver) too.
- ascotan 11y agoI was disappointed that the subtitle wasn't "tighter and tighter testing". http://i.imgur.com/1aD54YR.jpg http://i.imgur.com/1aD54YR.jpg
- coolstorybro22 11y agoSigh - more ruby rubbish. There are much cleaner and better and frankly less 'magic' tools available. Find them, use them, say no to ruby!
- CSDude 11y agoIf 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
- mtsmith85 11y agoCapybara 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.
- tonyhb 11y agoCapybara'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-capybara http://tonyhb.com/stop-treading-water-with-marionette-and-ca... 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.
- thibaut_barrere 11y agoIf 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 11y agoI 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 11y agoVery good point. I do this when I can so my suit runs much faster.
- lectrick 11y agoI 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.