Capybara finders re-implemented as custom Cypress commands
Switch branches/tags
Nothing to show
Clone or download
Latest commit 8502c4e Jul 15, 2018
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci circle config Jul 15, 2018
cypress standard Jul 15, 2018
lib standard Jul 15, 2018
.gitignore npm init Jul 14, 2018 example Jul 15, 2018
add-commands.js WIP Jul 15, 2018
cypress.json fix version of html fixture Jul 15, 2018
index.js WIP Jul 15, 2018
package-lock.json 0.0.2 Jul 15, 2018
package.json 0.0.2 Jul 15, 2018



An abbreviated port of Capybara's finder methods, reimplemented as custom Cypress commands.


npm install -D cypress-capybara

Then, in your cypress/support/commands.js file, add:

import 'cypress-capybara/add-commands'


Here are the commands cypress-capybara implements. As with Capybara proper, they specify pretty liberal search functions, allowing locators to specify interactive elements by label, display text, name, id, value, title, and so on (depending on the element type).

To see these in action, check out the library's test file.

Why haven't you implemented x method from Capybara::DSL?

The library will only port functions which can be reasonably deemed as worthwhile apart from the features provided by Cypress's built-in API–which is pretty robust, out of the box! Not only do many commands roughly mirror those in Capybara (e.g. cy.get() is essentially the same as find() or all(), whereas visit is even named the same thing in both libraries), but the chaining style used for Cypress enables a lot of the sort of operations that required separate methods, options, and blocks in Capybara.

Want to fill in a field? Just do findField('Some Label').type('some text'). If this library were to implement fillIn('Some Label', {with: 'some text'}), it would simply be redundant and, more importantly, it would prevent users from using the chaining API to do something like an intermediary filter() operation between finding matching fields and then invoking type().