Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Mutation testing for Ruby
Ruby Groff
Latest commit c92dcf4 @dkubb dkubb Merge pull request #503 from mbj/fix/api-use-in-corpus
Fix API usage in corpus tests


Build Status Dependency Status Code Climate Inline docs Gem Version Flattr

Mutant is a mutation testing tool for Ruby.

The idea is that if code can be changed and your tests do not notice, either that code isn't being covered or it does not have a speced side effect.

Mutant supports ruby >= 2.1, while support for JRuby is planned. It should also work under any Ruby engine that supports POSIX-fork(2) semantics.

Mutant uses a pure Ruby parser and an unparser to do its magic.

Mutant does not have really good "getting started" documentation currently so please refer to presentations and blog posts below.


As mutant right now only supports rspec, install the gem mutant-rspec via your preferred method. It'll pull the mutant gem (in correct version), that contains the main engine.

gem install mutant-rspec

The minitest integration is still in the works.


cd virtus
# Run mutant on virtus namespace
mutant --include lib --require virtus --use rspec Virtus*
# Run mutant on specific virtus class
mutant --include lib --require virtus --use rspec Virtus::Attribute
# Run mutant on specific virtus class method
mutant --include lib --require virtus --use rspec
# Run mutant on specific virtus instance method
mutant --include lib --require virtus --use rspec Virtus::Attribute#type


Occasionally mutant will produce a mutation with an infinite runtime. When this happens mutant will look like it is running indefinitely without killing a remaining mutation. To avoid mutations like this, consider adding a timeout around your tests. For example, in RSpec you can add the following to your spec_helper:

config.around(:each) do |example|
  Timeout.timeout(5_000, &example)

which will fail specs which run for longer than 5 seconds.


To mutation test Rails models with rspec comment out require 'rspec/autorun' from your spec_helper.rb file. Having done so you should be able to use commands like the following:

RAILS_ENV=test bundle exec mutant -r ./config/environment --use rspec User


Mutant cannot emit mutations for...

  • methods defined within a closure. For example, methods defined using module_eval, class_eval, define_method, or define_singleton_method:

      class Example
        class_eval do
          def example1
        module_eval do
          def example2
        define_method(:example3) do
        define_singleton_method(:example4) do
  • singleton methods not defined on a constant or self

    class Foo
      def; end   # ok
      def Foo.baz; end    # ok
      myself = self
      def myself.qux; end # cannot mutate
  • methods defined with eval:

    class Foo
      class_eval('def bar; end') # cannot mutate


Mutant supports a wide range of mutation operators. An exhaustive list can be found in the mutant-meta. The mutant-meta is arranged to the AST-Node-Types of parser. Refer to parsers AST documentation in doubt.

There is no easy and universal way to count the number of mutation operators a tool supports.


Mutant currently mutates code in instance and singleton methods. It is planned to support mutation of constant definitions and domain specific languages, DSL probably as plugins.


Mutation testing is slow. The key to making it fast is selecting the correct set of tests to run. Mutant currently supports the following built-in strategy for selecting tests/specs:

Mutant uses the "longest rspec example group descriptions prefix match" to select the tests to run.

Example for a subject like Foo::Bar#baz it will run all example groups with description prefixes in Foo::Bar#baz, Foo::Bar and Foo. The order is important, so if mutant finds example groups in the current prefix level, these example groups must kill the mutation.

Reading Reports

Mutation output is grouped by selection groups. Each group contains three sections:

  1. An identifier for the current group.




  2. A list of specs that mutant ran to try to kill mutations for the current group.




    - rspec:0:./spec/unit/book_spec.rb:9/Book#add_page should return self
    - rspec:1:./spec/unit/book_spec.rb:13/Book#add_page should add page to book
  3. A list of unkilled mutations diffed against the original unparsed source


    • [MUTATION TYPE] will be one of the following:
      • evil - a mutation of your source was not killed by your tests
      • neutral your original source was injected and one or more tests failed
    • [IDENTIFIER] - Unique identifier for this mutation


    @@ -1,6 +1,6 @@
    def add_page(page)
    -  @pages << page
    +  @pages
      @index[page.number] = page
    @@ -1,6 +1,6 @@
    def add_page(page)
    -  @pages << page
    +  self
      @index[page.number] = page


There are some presentations about mutant in the wild:

Blog posts

Sorted by recency:

The Crash / Stuck Problem (MRI)

Mutations generated by mutant can cause MRI to enter VM states its not prepared for. All MRI versions > 1.9 and < 2.2.1 are affected by this depending on your compiler flags, compiler version, and OS scheduling behavior.

This can have the following unintended effects:

  • MRI crashes with a segfault. Mutant kills each mutation in a dedicated fork to isolate the mutations side effects when this fork terminates abnormally (segfault) mutant counts the mutation as killed.

  • MRI crashes with a segfault and gets stuck when handling the segfault. Depending on the number of active kill jobs mutant might appear to continue normally until all workers are stuck into this state when it begins to hang. Currently mutant must assume that your test suite simply not terminated yet as from the outside (parent process) the difference between a long running test and a stuck MRI is not observable. Its planned to implement a timeout enforced from the parent process, but ideally MRI simply gets fixed.


Planning a presentation?

Mutation testing lately (not only mutant) seems to attract some attention. So naturally people do talks about it at conferences, user groups or other chances. Thanks for that!

As I (the author @mbj) am not too happy with some of the facts being presented about mutant the last month.

So if you plan to do a presentation: I offer to review your slides / talk - for free of course. My intention is NOT to change your bias pro / against this tool. Just to help to fix invalid statements about the tool.

Also in many cases a conversation to the author should help you to improve the talk significantly. One of mutants biggest weaknesses is the bad documentation, but instead of assumptions based on the absence of docs, use the tool authors brain to fill the gaps.

Hint, same applies to papers.


I'm very happy to receive/answer feedback/questions and criticism.

Your options:

There is also a mutant slack chat. @mention @_m_b_j_ on twitter for an invite.



  • Fork the project.
  • Make your feature addition or bug fix.
  • Add tests for it. This is important so I don't break it in a future version unintentionally.
  • Commit, do not mess with Rakefile or version (if you want to have your own version, that is fine but bump version in a commit by itself I can ignore when I pull)
  • Send me a pull request. Bonus points for topic branches.


See LICENSE file.

Something went wrong with that request. Please try again.