Minimally Intrusive SimpleCov Loading
Posted by matijs 02/04/2016 at 16h55
I always like extra developer tooling to be minimally intrusive, to avoid forcing it on others working with the same code. There are several aspects to this: Presence of extra gems in the bundle, presence and visibility of extra files in the repository, and presence of extra code in the project.
For this reason, I’ve been reluctant to introduce tools like guard or some of the Rails preloaders that came before Spring. On the other hand, no-one would be bothered by my occasional running of RuboCop, Reek or pronto.
In this light, I’ve always found SimpleCov a little too intrusive: It needs to
be part of the bundle, and the normal way to set things up makes it rather
prominently visible in your test or spec helper. Nothing too terrible, but I’d
like to just come to a project, run something like simplecov rake spec
, and
have my coverage data.
I haven’t reached that blissful state of casual SimpleCov use yet, but I’m quite pleased with what we achieved for Reek.
Here’s what we did:
- Add
simplecov
to the Gemfile - Add a
.simplecov
file with configuration:
SimpleCov.start do
track_files 'lib/**/*.rb'
# version.rb is loaded too early to test
add_filter 'lib/reek/version.rb'
end
SimpleCov.at_exit do
SimpleCov.result.format!
SimpleCov.minimum_coverage 98.9
SimpleCov.minimum_coverage_by_file 81.4
end
- Add
-rsimplecov
to theruby_opts
for our spec task:
RSpec::Core::RakeTask.new('spec') do |t|
t.pattern = 'spec/reek/**/*_spec.rb'
t.ruby_opts = ['-rsimplecov -Ilib -w']
end
This has several nice features:
First, there are no changes to spec_helper.rb
. That file can get pretty
cluttered, so the less has to be in there, the better.
Second, it only calculates coverage when running the full suite with rake spec
. This means running just one spec file while developing won’t clobber
your coverage data, and it makes running single specs a little faster since it
doesn’t need to update the coverage reports.
Third, it enforces a minimum coverage per file and for the whole suite. The second point helps a lot in making this practical: Otherwise, running individual specs would almost always fail due to low coverage.