RSpec 3.8 support

[spikeheap]

From mutant/mutant-rspec.gemspec, it appears that mutant is dependent on rspec-core '>= 3.4.0', '< 3.8.0':

gem.add_runtime_dependency('rspec-core', '>= 3.4.0', '< 3.8.0')

We are using rspec-core 3.8.0, and Bundler complains that there is a dependency conflict .

In my Gemfile, I have:

gem 'mutant-rspec',               '~> 0.8.15'

But when I run bundle install, I get:

Bundler could not find compatible versions for gem "rspec-core":
  In snapshot (Gemfile.lock):
    rspec-core (= 3.8.0)

  In Gemfile:
    mutant-rspec (~> 0.8.15) was resolved to 0.8.15, which depends on
      rspec-core (< 3.8.0, >= 3.4.0)

    rspec (~> 3.0) was resolved to 3.8.0, which depends on
      rspec-core (~> 3.8.0)

Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.

[mbj]

I've created #745 that should address this, it also has a bit of backstory on why the restrictions on the rspec versions where like this.

[mbj]

Just released mutant-0.8.16 with rspec-3.x whitelisted.

[mbj]

@spikeheap BTW: I'm always curious, what is your usecase for mutant?

[spikeheap]

Great, thanks @mbj. I've been using mutant to highlight test brittleness with clients. It's really useful to have a concrete tool output rather than relying on hypotheticals. I started looking for a mutation-testing tool because I'd had good results with http://pitest.org/ in my Java days.

Cheers for all your work on this :).

[mbj]

@spikeheap Interesting, can you elaborate a bit what exactly

highlight test brittleness with clients

is? I have a vague idea, but as I never used mutant outside "guarding a development iteration for weak semantics in code or tests" I'm super curious on how responsive clients are to what you are doing.

[spikeheap]

@mbj absolutely, and adding it as a CI check alongside coverage/linting is a good call. As I'm often consulting/contracting, it's nice to be able to run PIT/mutant over a codebase I'm new to (or a tiny portion of it), and come back with recommendations which help the team grow at the same time as cleaning up the code. It's often easy to see patterns, and combining that with git blame gives me an idea of what to look out for in upcoming PRs and mentor other developers to overcome.

[mbj]

@spikeheap k, this is actually more close to what I do on similar activities.

BTW: Retroactively applying mutant to a code base on CI is best done via using the --since feature. It allows automated incremental mutation testing that will only try to cover the current diff.

Feel free to ping me in private in case you see the need for hands on help with mutant on a specific clients code base. There are lots of strategies / tactics that can make the difference between "ready for CI" or "only a demonstration tool".