Complex rspec specs can intermittently fail in continuous integration

We use an external service to perform our full suite of unit and integration rspec tests on every push of changes to our revision control repository.

We’ve found that tests that pass locally end up failing or, even worse, intermittently failing (flap) when run by the Continuous Integration service.

This is often due to dependencies that are available locally but are not part of our project or correctly prepared for in our tests.

Another common reason is complex test code that becomes fragile in the context of the third party CI environment.

So, here are some things I look to clean up when I see a ‘flapping’ spec:

  • Use factories. Rather than update models after creating them change the factory to accept a transient attribute and modify or add dependent models in an after build or create block. In other words try not to persist to the database in code in the spec itself particularly if it is a feature spec.
  • Assign variables using let blocks rather than within tests or before blocks.
  • code>mkdir_p before writing files to tmp directories to ensure the directory will exist when you need it.
  • Create straightforward assertions. Have one expectation per test unless the runtime savings of combining a group into a single test clearly outweighs the complexity and potential fragility you’re introducing.

Most of these are best practice for rspec tests. As with many things in software, following a recommended pattern avoids unpleasant surprises because smart people have solved problems before you can stumble into them.

Before cleanup

After cleanup