In the development team of Resultados Digitais we use Test Driven Development (TDD) . This practice, in addition to mitigating errors that could be introduced by new requirements, helps to maintain code quality.

Tests serve as code documentation and provide more security for developers. Still, a covered code testing can generate an overhead runtime, which can be the bottleneck between the development and deployment into production.

In this post I will explain how we detect and attack the main problems of our tests with Factory Girl and RSpec , optimizing the execution time and preventing errors.

Where do we spend our time

We are data-driven. When we talk about test runtime, we’re talking about additional time to put an improvement on the air. So, if that time is too long, we lose productivity – we get fewer updates per day.

To reduce this time and make the team more agile, we focus on three points:

  1. Factories specialization for better test performance.
  2. Fixed tests that erroneously report false positives.
  3. Improved testing for better documentation quality and error traceability.

Specializing factories for better test performance

One of the difficulties in modeling a test is to interact or simulate the behavior of database objects. In Ruby on Rails , a library (gem) quite widespread for its simplicity and efficiency is the Factory Girl . This gem is a domain-specific language ( DSL ) for creating and defining object factories ( factories ), which inherit their behaviors and attributes from the business model classes (ActiveRecord).

One of the benefits of Factory Girl is that we can define associations between model objects. However, this can also be a problem, as the gem creates these associations by default and therefore may slow down testing.

False positive: associations in tests causing failures

One problem we face when working with automated tests is that of false positives. These are tests that in theory are correct, but in practice fail. Rails ActiveRecord has a very strong connection to the database and its constraints. The unique restriction for some attributes, such as identifiers, must be respected directly in the model.

To generate random data for our tests, we used the Faker gem . This gem is capable of generating varied data such as emails, names, addresses, etc. When using this tool, it is necessary to take into account whether the attributes for the random data that will be generated have the restriction of being unique

Our deployment process goes through a continuous integration step in which we use the CircleCI service . If a test fails, it is part of the process to verify the cause and correct it, but this is a manual process. In other words, a failure in the process causes the deployment time to increase considerably. Therefore, false positives are a bottleneck. The following image shows a false positive in our continuous integration tool:

fail in circleci

Here at RD we solve false positives by investigating case by case, taking actions according to the type of problem. The main action we took was to remove the associations that were not useful for testing.

Final considerations

Good practices and care when writing your tests will improve your execution time, increase the consistency of your documentation, and stop RSpec from accusing non-existent failures, the so-called false positives. This increases the team’s productivity and prevents possible errors in production.