Rails applications are likely to have a variety of automated tests and even a handful of manual tests. At Magpie we use a combination of unit tests and Selenium on Rails, so the code coverage metric for unit tests never quite adds up to what is expected. I’d bet that on most Rails projects getting coverage to 100% seems impossible from a unit test standpoint. I’m going to describe a way to combine code coverage results from all testing done on a product. It’s relatively easy to do.
First, install rcov. Gemcutter.org has the latest version with sortable charts.
Windows users may run into an error about nmake. If that happens try installing an older version of rcov.
Start the server with rcov:
Now that the server is up, run all of the manual and/or Selenium tests. When the tests are finished, hit Ctrl-C back at the command line to generate a report and the coverage.data file. Check out the results at test/coverage/index.html. Watch out because running the next step will overwrite the report.
Append the following rake task to the Rails project Rakefile.
namespace :test do
Rcov::RcovTask.new("coverage") do |t|
t.libs << "test"
t.test_files = FileList["test/**/*_test.rb"]
t.output_dir = "test/coverage/"
t.verbose = true
t.rcov_opts << ["--sort coverage",
"--rails",
"--exclude /gems/",
"--aggregate coverage.data"]
end
end
This will provide the rake test:coverage task that you may already be familiar with. The main difference in the task is that it adds its results to the coverage.data file. Run it next:
The updated coverage results should contain a very clear picture of what isn’t covered by testing at this point. The Rails community has many different testing techniques, so this won’t work for everyone. Hopefully from reading this you can still compose a strategy for seeing the full coverage of your tests.
Note: Make sure to delete the coverage.data file before test runs otherwise the left over data is likely to cause confusion.
Magpie develops software solutions for a variety of clients. When we secure a new client project, it requires a lot of learning to understand the project domain, legacy code, project tool chain, and other project technologies. Since we run our projects via agile methods, much of this learning is captured in task cards called “Spikes”.