Skip to content

Latest commit

 

History

History
339 lines (229 loc) · 19 KB

README.md

File metadata and controls

339 lines (229 loc) · 19 KB
Raw

RSpec Rails Examples Build Status Join the chat at https://gitter.im/eliotsykes/rspec-rails-examples

An RSpec cheatsheet in the form of a Rails app. Learn how to expertly test Rails apps from a model codebase

A small yet comprehensive reference for developers who want to know how to test Rails apps using RSpec.

Here you'll find in-depth examples with detailed documentation explaining how to test with RSpec and related testing gems, which you can then apply to your own projects.

This application was originally written for the benefit of the developers I coach, who've found it a useful memory aid and catalyst for when they're learning RSpec. Now I'd like to get feedback from the wider community.

The repo contains examples of various spec types such as feature, mailer, and model. See the spec/ directory for all the example specs and types.

In the README below, you'll find links to some of the most useful cheatsheets and API documentation available for RSpec users.

See the well-commented files in the spec/support directory for walkthroughs on how to configure popular testing gems, such as DatabaseCleaner, Capybara, and FactoryGirl.

Hopefully this will be of help to those of you learning RSpec and Rails. If there's anything missing you'd like to see covered in the project, please submit your request via the issue tracker, I'd be happy to help — Eliot Sykes

PS. Interested in growing your skills and supporting this project? Learn with the TDD Masterclass, get Test Coverage First Aid for your app, or grow with one-to-one coaching for Rails developers.

Support Configuration

The tests rely on this configuration being uncommented in spec/rails_helper.rb, you probably want it uncommented in your app too:

# Loads `.rb` files in `spec/support` and its subdirectories:
Dir[Rails.root.join("spec/support/**/*.rb")].each { |f| require f }

(The rspec-rails installer generates this line, but it will be commented out.)

Run Specs in a Random Order

In a dependable, repeatable automated test suite, data stores (such as database, job queues, and sent email on ActionMailer::Base.deliveries) should return to a consistent state between each spec, regardless of the order specs are run in.

For a maintainable, predictable test suite, one spec should not set up data (e.g. creating users) needed by a later spec to pass. Each spec should look after its own test data and clear up after itself. (NB. If there is reference data that all tests need, such as populating a countries table, then this can go in db/seeds.rb and be run once before the entire suite).

The specs run in a random order each time the test suite is run. This helps prevent the introduction of run order and test data dependencies between tests, which are best avoided.

Random order test runs are configured using the config.order = :random and Kernel.srand config.seed options in spec/spec_helper.rb.

Testing Production Errors

When errors are raised, the Rails test environment may not behave as in production. The test environment may mask the actual error response you want to test. To help with this, you can disable test environment exception handling temporarily, spec/support/error_responses.rb provides respond_without_detailed_exceptions. See it in use in spec/api/v1/token_spec.rb to provide production-like error responses in the test environment.

Testing Rake Tasks with RSpec

RSpec testing Rake task configuration and example:

Pry-rescue debugging

pry-rescue can be used to debug failing specs, by opening pry's debugger whenever a test failure is encountered. For setup and usage see pry-rescue's README.

Time Travel Examples

ActiveSupport::Testing::TimeHelpers provides helpers for manipulating and freezing the current time reported within tests. These methods are often enough to replace the time-related testing methods that the timecop gem is used for.

TimeHelpers configuration how-to and examples:

ActiveJob Examples

ActiveJob::TestHelper provides help to test ActiveJob jobs.

ActiveJob::TestHelper configuration how-to and examples:

Database Cleaner Examples

Database Cleaner is a set of strategies for cleaning your database in Ruby, to ensure a consistent environment for each test run.

Database Cleaner configuration how-to:

Factory Girl Examples

Factory Girl is a library to help setup test data. factory_girl_rails integrates Factory Girl with Rails.

Factory Girl configuration how-to and examples:

VCR Examples

VCR records your test suite's HTTP interactions and replays them during future test runs. Your tests can run independent of a connection to external URLs. These HTTP interactions are stored in cassette files.

VCR configuration how-to and examples:

Capybara Examples

Capybara helps you write feature specs that interact with your app's UI as a user does with a browser.

Capybara configuration how-to and examples:

Puffing Billy Examples

Puffing Billy is like VCR for browsers used by feature specs. Puffing Billy is a HTTP proxy between your browser and external sites, including 3rd party JavaScript. If your app depends on JavaScript hosted on another site, then Puffing Billy will keep a copy of that JavaScript and serve it from a local web server during testing. This means tests dependent on that JavaScript will carry on working even if the original host cannot be connected to.

If you need to debug Puffing Billy, refer to its output in log/test.log.

Puffing Billy configuration how-to and examples:

Shoulda-Matchers Examples

Shoulda-matchers make light work of model specs.

shoulda-matchers configuration how-to and examples:

Email-Spec Examples

The "Subscribe to newsletter" feature was developed with help from email_spec

email_spec configuration how-to and examples:

Devise Examples

Specs testing registration, sign-in, and other user authentication features provided by Devise:

Custom Matchers

You can write your own custom RSpec matchers. Custom matchers can help you write more understandable specs.

Custom matchers configuration how-to and examples:

RSpec-Expectations Docs

RSpec-Mocks Specs & Docs

RSpec-Rails

See RSpec Rails for installation instructions.

Matchers

Generators

Feature Specs & Docs

API Request Specs, Docs, & Helpers

Mailer Specs & Docs

Controller Specs & Docs

View Specs & Docs

Helper Specs & Docs

Routing Specs & Docs

Validator Specs

To test a custom validator you've written, refer to these validator specs from other Rails projects. These specs each follow a similar pattern where the validator is tested with a dummy model that is defined and used within the spec only. Using a dummy model is usually preferable to writing a validator spec that is dependent on a real model.

Related task: Demonstrate Validator Specs within rspec-rails-examples

Enable Spring for RSpec

Spring is a Rails application preloader. It speeds up development by keeping your application running in the background so you don't need to boot it every time you run a new command.

To take advantage of this boost when you run bin/rspec, the spring-commands-rspec gem needs to be installed and a new rspec binstub needs to be created:

# 1. Add `spring-commands-rspec` to Gemfile in development and test groups and
#    install gem:
bundle install

# 2. Spring-ify the `bin/rspec` binstub:
bundle exec spring binstub rspec

# 3. Stop spring to ensure the changes are picked up:
bin/spring stop

# 4. Check bin/rspec is still working:
bin/rspec

See the spring-commands-rspec README for up-to-date installation instructions: https://github.com/jonleighton/spring-commands-rspec

Automated Continuous Integration with Travis CI

Continuous Integration (CI) is the practice of integrating new code into the master branch frequently, to help detect merge conflicts, bugs, and improve the quality of the software a development team writes.

CI is usually accompanied by running an application's test suite against the latest code changes, and flagging any test failures that are found. Developers are expected to investigate and fix these failures to maintain a passing test suite and therefore quality.

Travis CI is a build server that helps automate the CI process. Travis CI runs an application's tests against the latest changes pushed to the application's code respository. In this project, Travis CI runs the project's tests (rake test) on pull requests and on changes to the master branch.

Travis CI configuration how-to and example:

Contributors