Skip to content

Testing standards and style guidelines

This document describes various guidelines and best practices for automated testing of the GitLab project.

It is meant to be an extension of the thoughtbot testing styleguide. If this guide defines a rule that contradicts the thoughtbot guide, this guide takes precedence. Some guidelines may be repeated verbatim to stress their importance.

Overview

GitLab is built on top of Ruby on Rails, and we're using RSpec for all the backend tests, with Capybara for end-to-end integration testing. On the frontend side, we're using Karma and Jasmine for JavaScript unit and integration testing.

Following are two great articles that everyone should read to understand what automated testing means, and what are its principles:

Testing levels

Learn about the different testing levels, and how to decide at what level your changes should be tested.

Testing best practices

Everything you should know about how to write good tests: RSpec, FactoryGirl, system tests, parameterized tests etc.

Frontend testing standards and style guidelines

Everything you should know about how to write good Frontend tests: Karma, testing promises, stubbing etc.

Flaky tests

What are flaky tests, the different kind of flaky tests we encountered, and what we do about them.

GitLab tests in the Continuous Integration (CI) context

How GitLab test suite is run in the CI context: setup, caches, artifacts, parallelization, monitoring.

Testing Rake tasks

Everything you should know about how to test Rake tasks.

Spinach (feature) tests

GitLab moved from Cucumber to Spinach for its feature/integration tests in September 2012.

As of March 2016, we are trying to avoid adding new Spinach tests going forward, opting for RSpec feature specs.

Adding new Spinach scenarios is acceptable only if the new scenario requires no more than one new step definition. If more than that is required, the test should be re-implemented using RSpec instead.

Return to Development documentation