This guide outlines standards and best practices for automated testing of GitSwarm CE and EE.
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.
GitSwarm uses factory_girl as a test fixture replacement.
spec/factories/, named using the pluralization of their corresponding model (User factories are defined in users.rb).create(...) instead of FactoryGirl.create(...).ActiveRecord objects. See example.GitSwarm uses Teaspoon to run its Jasmine JavaScript specs. They can be run on the command line via bundle exec teaspoon, or via a web browser at http://localhost:3000/teaspoon when the Rails server is running.
spec/javascripts/, matching the folder structure of app/assets/javascripts/: app/assets/javascripts/behaviors/autosize.js.coffee has a corresponding spec/javascripts/behaviors/autosize_spec.js.coffee file.Haml fixtures required for JavaScript tests live in spec/javascripts/fixtures. They should contain the bare minimum amount of markup necessary for the test.
Warning: Keep in mind that a Rails view may change and invalidate your test, but everything will still pass because your fixture doesn't reflect the latest view.
Keep in mind that in a CI environment, these tests are run in a headless browser and you will not have access to certain APIs, such as Notification, which will have to be stubbed.
describe ClassName block.described_class instead of repeating the class name being described..method to describe class methods and #method to describe instance methods.context to test branching logic.describe symbols (see Gotchas).:each argument to hooks since it's the default.not_to to to_not (this is enforced by Rubocop).let variablesGitSwarm's RSpec suite has made extensive use of let variables to reduce duplication. However, this sometimes comes at the cost of clarity, so we need to set some guidelines for their use going forward:
let variables are preferable to instance variables. Local variables are preferable to let variables.let to reduce duplication throughout an entire spec file.let to define variables used by a single test; define them as local variables inside the test's it block.let variable inside the top-level describe block that's only used in a more deeply-nested context or describe block. Keep the definition as close as possible to where it's used.let variable with another.let variable that's only used by the definition of another. Use a helper method instead.GitSwarm has a massive test suite that, without parallelization, can take more than an hour to run. It's important that we make an effort to write tests that are accurate and effective as well as fast.
Here are some things to keep in mind regarding test performance:
double and spy are faster than FactoryGirl.build(...)FactoryGirl.build(...) and .build_stubbed are faster than .create.create an object when build, build_stubbed, attributes_for, spy, or double will do. Database persistence is slow!create(:empty_project) instead of create(:project) when you don't need the underlying Git repository. Filesystem operations are slow!@javascript in Spinach or js: true in RSpec) unless it's actually required for the test to be valid. Headless browser testing is slow!spec/features/ and should be named ROLE_ACTION_spec.rb, such as user_changes_password_spec.rb.feature block per feature spec file.GitSwarm 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.