minitest-parallel_fork adds fork-based parallelization to Minitest. Each test/spec suite is run in one of the forks, allowing this to work correctly when using before_all/after_all/around_all hooks provided by minitest-hooks. Using separate processes via fork can significantly improve spec performance when using MRI, and can work in cases where Minitest’s default thread-based parallelism do not work, such as when tests/specs modify the constant namespace.

gem install minitest-parallel_fork 

Source code is available on GitHub at github.com/jeremyevans/minitest-parallel_fork

You can enable fork-based parallelism just by requiring minitest/parallel_fork. One easy to do so without modifying the spec code itself is to use the RUBYOPT environment variable. So if you execute your specs using:

rake spec 

You can switch to fork-based parallelism using:

RUBYOPT=-rminitest/parallel_fork rake spec

To control the number of forks, you can set the NCPU environment variable:

NCPU=8 RUBYOPT=-rminitest/parallel_fork rake spec

If you don’t set the NCPU environment variable, minitest-parallel_fork will use 4 forks by default.

In some cases, especially when using external databases, you’ll need to do some before fork or after fork setup. minitest/parallel_fork supports before_parallel_fork and after_parallel_fork hooks.

before_parallel_fork is called before any child processes are forked:

Minitest.before_parallel_fork do DB.disconnect end 

after_parallel_fork is called after each child process is forked, with the number of the child process, starting at 0:

Minitest.after_parallel_fork do |i| DB.opts[:database] += (i+1).to_s end 

The above examples show a fairly easy way to use minitest-parallel_fork with an external database when using Sequel. Before forking, all existing database connections are disconnected, and after forking, the database name is changed in each child to reference a child-specific database, so that the child processes do not share a database and are thus independent.

There is also a hook for debugging. on_parallel_fork_marshal_failure is called if there is an error unmarshalling data sent from the child process to the parent process. This can happen if one of the child processes exits unexpected during the test, before it reports results.

Minitest.on_parallel_fork_marshal_failure do # Gather relevant logs for more debugging end 

If you would like to run tests in parallel, but stop running tests at the first failure, you can use:

RUBYOPT=-rminitest/parallel_fork/fail_fast rake spec

Note that minitest-parallel_fork uses suite-based parallelism, so tests will not stop until one child has a failing test suite (test class that has a failing test method), and other children are signaled and also stop processing.

To use this with Rails/ActiveRecord, you probably want to use hooks similar to:

Minitest.before_parallel_fork do ActiveRecord::Base.connection.disconnect! end Minitest.after_parallel_fork do |i| db_config = Rails.application.config.database_configuration[Rails.env].clone db_config['database'] += (i+1).to_s ActiveRecord::Base.establish_connection(db_config) end 

The speedup you get greatly depends on your specs. Here’s some examples using Sequel’s specs:

 2 forks 4 forks spec_core: 1.25x - 1.36x 1.5x spec_model: 1.29x - 1.62x 1.72x - 2.02x spec_plugin: 1.57x - 1.76x 2.29x - 2.37x spec_sqlite: 1.75x - 1.86x 2.26x - 2.65x spec_postgres: 1.32x - 1.40x Untested

MIT

Jeremy Evans <code@jeremyevans.net>