By default, mutant will test mutations in parallel by running up
to one process for each core on your system. You can control the
number of processes created using the -j/--jobs argument.
Mutant forks a new process for each mutation to be tested to prevent side effects in your specs and the lack of thread safety in integrations from impacting the results.
If the code under test relies on a database, you may experience problems when running mutant because of conflicting data in the database. For example, if you have a test like this:
resource = MyModel.create!(...)
expect(MyModel.first.name).to eql(resource.name)It might fail if some other test wrote a record to the MyModel table
at the same time as this test was executed. (It would find the MyModel
record created by the other test.) Most of these issues can be fixed
by writing more specific tests. Here is a concurrent safe version of
the same test:
resource = MyModel.create!(...)
expect(MyModel.find_by_id(m.id).name).to eql(resource.name)
An alternative is to try wrapping each test into an enclosing transaction.
For production-grade database isolation, use hooks to create separate databases or database files for each worker process. Rails applications can use the patterns in Rails Integration, including PostgreSQL template databases and SQLite database-file copies.
Do not share one SQLite database file across parallel workers. If you cannot create
worker-specific database copies, set --jobs to 1.
- Test Runner - Verify parallel execution works before mutation testing
- Rails Integration - Rails database isolation examples
- Hooks - Database isolation examples for parallel workers