Automated code reviews via mutation testing - semantic code coverage (fork of the latest free version)
Find a file
2014-04-04 14:18:45 +00:00
bin
config Fix reek issues 2014-04-04 14:18:45 +00:00
lib Fix reek issues 2014-04-04 14:18:45 +00:00
spec
test_app
.gitignore
.rspec
.rubocop.yml
.ruby-gemset
.travis.yml
Changelog.md
circle.yml
Gemfile
Gemfile.devtools
Guardfile
LICENSE
mutant-rspec.gemspec
mutant.gemspec
Rakefile
README.md
TODO

mutant

Build Status Dependency Status Code Climate Inline docs

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.

A more readable introduction can be found under: http://solnic.eu/2013/01/23/mutation-testing-with-mutant.html

Mutant supports MRI and RBX 1.9 and 2.0, while support for jruby is planned. It should also work under any ruby engine that supports POSIX-fork(2) semantics. Support for MRI 2.1 is unstable, because this MRI release segfaults on basic metaprogramming mutants dependencies do.

Integrations

Only rspec2 and rspec-3 beta2 is supported currently.

Projects using Mutant

The following projects adopted mutant, and aim 100% mutation coverage:

Feel free to ping me to add your project to the list!

Installation

Install the gem mutant via your preferred method.

gem install mutant

If you plan to use the rspec integration you'll have to install mutant-rspec also. Please add an explicit dependency to rspec-core for the rspec version you want to use.

gem install mutant-rspec

Mutations

Mutant supports a very wide range of mutation operators. Listing them all in detail would blow this document up.

It is planned to parse a list of mutation operators from the source. In the meantime please refer to the code each subclass of Mutant::Mutator::Node emits around 3-6 mutations.

Currently mutant covers the majority of ruby's complex nodes that often occur in method bodies.

Some stats from the axiom library:

Subjects:  424       # Amount of subjects being mutated (currently only methods)
Mutations: 6760      # Amount of mutations mutant generated (~13 mutations per method)
Kills:     6664      # Amount of successfully killed mutations
Runtime:   5123.13s  # Total runtime
Killtime:  5092.63s  # Time spend killing mutations
Overhead:  0.60%
Coverage:  98.58%    # Coverage score
Alive:     96        # Amount of alive mutations.

Nodes still missing a dedicated mutator are handled via the Generic mutator. The goal is to remove this mutator and have dedicated mutator for every type of node and removing the Generic handler altogether.

Examples

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 ::Virtus::Attribute.build
# Run mutant on specific virtus instance method
mutant --include lib --require virtus --use rspec ::Virtus::Attribute#type

Presentations:

There are some presentations about mutant in the wild:

Subjects:

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.

Test-Selection

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.

This test selection strategy is compatible with the old --rspec-dm2 and --rspec-unit strategy. The old flags were removed. It allows to define very fine grained specs, or coarse grained - as you like.

Support

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

Your options:

Credits

Contributing

  • 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.

License

See LICENSE file.