Skip to content

Testing_Conventions

Gavin Morrice edited this page Aug 14, 2018 · 5 revisions

DMPRoadmap Testing Conventions

This project started out with close to zero tests. Please help us improve our test coverage by ensuring that any new code you push is well-tested, and by adding additional tests where you see they are needed.

Running the tests

We use RSpec for unit testing, and RSpec with Capybara for integration testing.

You can run the entire Ruby test suite with the following command:

$ bundle exec rspec spec

(Using the bundle keyword helps to ensure we're using the rspec executable in the bundled RSpec version).

Basic Guidelines

  • Tests MUST pass before a PR can be accepted and merged
  • Format your tests as recommended in the Better Specs guide
  • Test any methods that have been defined for both positive and negative outcomes
  • Test model associations (use Shoulda)
  • Test model attribute validations (use Shoulda)
  • Test model callbacks: after_save, before_validation, etc.
  • Test model scopes to ensure that they filter the correct data
  • Do not test private methods
  • Do not unit test controllers. These tests are normally difficult to maintain and rely heavily on stubbed data
  • Use RSpec feature specs for testing controllers with UI endpionts
  • Use RSpec request specs for testing controllers with JSON endpoints
  • Define one assertion per RSpec example (unless in feature specs)

Factories, not fixtures

This test suite relies on Factories, not fixtures. This is preferrable, since fixtures are inserted to the database without running ActiveRecord validations and checks. Factories allow us to run each test on a unique record, whereas fixtures give us only a small set of pre-defined test objects. This allows us to catch more potential bugs.

To learn more about how to use Factories, please read the Getting Started guide

Fake it when you make it

Use the Faker gem to generate dummy data for testing.

Bad

@user = User.new(email: '[email protected]')
expect(@user).to be_valid

Good

@user = User.new(email: Faker::Internet.email)
expect(@user).to be_valid

Headless Chrome

Running the feature specs requires Headless Chrome.

You can check you have the minimum requireqments by running the following bash shell command:

chromedriver --version

This should be at least ChromeDriver 2.41.578706 (5f725d1b4f0a4acbf5259df887244095596231db)

To update your ChromeDriver version, use:

chromedriver-update

Coverage

The test suite has SimpleCov installed. This should be used to monitor the quality of code as we progress. We are aiming for a healthy minimum coverage level of 80% to ensure the quality of the code is preserved over time.

UI Tests

UI tests are written in RSpec using the Capyabra gem. Tests are run using Selenium with Headless Chrome.

UI Tests With JS

NOTE: Ensure the :js flag is used in any feature Specs that rely on Javascript to run. For performance, we run feature specs in a lighter driver unless Javascript testing is required. To run a given test in Capybara with Selenium you must explicitly specify the js flag.

Example:

require "rails_helper"
describe "Account creation", type: :feature do 
  scenario "User creates an account", :js do # <= see the :js flag here?
    # Run tests that require Javascript in the browser.
  end
end

JS Tests

Explanation of npm test and our very spotty coverage coming soon ...


Clone this wiki locally