parralelizing rails tests

December 12, 2022


Recently I spent a couple weeks untangling and refactoring a pretty slow test suite for a client of mine.

It was a pretty straightforward CRUD app in the food industry sector but as time progressed and contractors came and went, the application grew and with it the test suite.

The main reason for lack of parallelization was due to the fact that a lot of parts of the codebase were built ad-hoc using one-off consultants and freelancers. Each person had their own little corner of the codebase that they created and they all left a chunk of tests.

The test runtime ended up taking approximately nine hours on a top-of-the-shelf macbook pro. Cloud runners couldn’t parallelize the work due to tight coupling of tests.


How did I get out of it? Strap in, I’ll show you.

  • Isolating tests

    • That was the biggest chunk of work and was most involved.

      • Needed to understand the domain
      • Refactor classes for loose coupling or no coupling at all
      • Remove dependencies on state or data modified by other tests
  • Add a couple important gems

  • Configure them!
  • Run your tests in parallel
  • Weep sweet tears of joy at how fast your brave CPU is working through them.
  • Tell your pipeline provider that you want parallel cores (here’s how you do it in github actions or circleci)
  • Create artifacts that let you know how long the tests took and MONITOR THEM MOVING FORWARD. Remember, what gets measured, gets done.


Two things.

Firstly, the real heavy lifting is the untangling and refactoring. **no amount of parallelization will help if your tests are interlocked and interdependent on each other.

Secondly, please go to the docs of both libs and do your own step-by-step extensions of what I described above, since things change over time. But I gave you the gist. Now go run with it.

Written by Daniel Kaczmarczyk, a software engineer and educator. you can find me on twitter or email me at

a pale blue and yellow circle