Capybara Style Guide

Introduction

Role models are important.

— Officer Alex J. Murphy / RoboCop

This Capybara style guide outlines the recommended best practices for real-world programmers to write code that can be maintained by other real-world programmers.

RuboCop, a static code analyzer (linter) and formatter, has a rubocop-capybara extension, provides a way to enforce the rules outlined in this guide.

You can generate a PDF copy of this guide using AsciiDoctor PDF, and an HTML copy with AsciiDoctor using the following commands:

# Generates README.pdf
asciidoctor-pdf -a allow-uri-read README.adoc

# Generates README.html
asciidoctor README.adoc

Tip	Install the `rouge` gem to get nice syntax highlighting in the generated document. `gem install rouge`

This guide is work in progress - trying to fill in the arguments by which the rubocop-capbyara cops were written so that users can understand the tradeoffs on different approaches (whether to configure, enable or disable different cops) and understand where it’s a question of consistency and/or style, or are there other issues at play.

You can also support the project (and RuboCop) with financial contributions via Patreon.

How to Contribute?

It’s easy, just follow the contribution guidelines below:

Fork the project on GitHub
Make your feature addition or bug fix in a feature branch
Include a good description of your changes
Push your feature branch to GitHub
Send a Pull Request

License

Creative Commons License This work is licensed under a Creative Commons Attribution 3.0 Unported License

Credit

TBC!

Capybara Style Guide

Table of Contents

Introduction

A Living Document

Using Capybara

Use a specific click_link or click_button to surface accessibility issues

But if you do use a generic click then use a consistent method

Don’t set expectations on Capybara `current_path`

Don’t use deprecated style methods

Either use of `have_no_*` or use `not_to` consistently for negated expectations

Be concise: don’t use redundant withins

Be specific: Use the most specific action rather than a generic action with parameters.

Be specific: Use the most specific finder rather than a generic finder with parameters

Be specific: Use the most specific matcher rather than a generic matcher with parameters

Don’t use visible: false in Capybara finders, instead use a specific visibility symbol

Using Capybara with RSpec

Use `have_css` or `have_xpath` instead of `have_selector`

Prefer using predicate matcher over using predicate method directly

Contributing

How to Contribute?

License

Credit