Minitest Parallelization and You

Published 2012-12-12 @ 00:00

Tagged minitest

As announced at RubyConf 2012, minitest 4.2.0 was released with parallelization added. As I said then, I don’t care in the slightest about trying to make your tests run faster. You deserve your pain if you write slow tests. What I do care about greatly is making your tests hurt and this will do that.

Minitest added randomization back in 2008 (afaik, before anyone else, it even took rspec 4 years to follow suit) as an easy means of ensuring your tests were actually independent of each other. Parallelization will take that a step further and make sure you don’t have any dependencies across test suites.

So, how do you use it? Parallelization is opt-in only but very easy to do:

class TestMyPain < Minitest::Unit::TestCase
  parallelize_me!

  # ...
end

describe MyPain do
  parallelize_me!

  # ...
end

All parallelize_me! does is override test_order to return :parallel. The runner will take care of the rest. All parallel suites will be run in parallel. Remaining serial suites will be run after.

If you want to try it out globally, you can shortcut via:

require "minitest/hell"

It changes the default order from :random to :parallel. Expect stuff to break, it is named appropriately.

What Should You Make Parallel?

Ideally, everything… But that’s not terribly realistic. Some things are just better left serialized. For example, testing $stdout, $stderr, and $stdin because they’re global, they’re perfectly happy to print whatever you want whenever you want, but capture_io and assert_output won’t work right. You should move those tests to a serial suite so everything else can run parallel.

Try it out. Have fun. Find and fix bugs. Enjoy.