A deeper dive into how covr works, particularly how it deals with collecting coverage from multiple child R processes.
Code coverage records whether or not each line of code in a package is executed by the package's tests. While it does not check whether a given program or test executes properly it does reveal areas of the code which are untested. Coverage has a long …
A talk on my R packages, lintr and covr
Track and report code coverage for your package and (optionally) upload the results to a coverage service like [Codecov](http://codecov.io) or [Coveralls](http://coveralls.io).
Being primarily a statistical language R lacks a number of common code analysis tools available for languages used more often for general programming. Testing has been done in the R source from very early on (Martin Maechler started adding tests on April 9th, 1998, 17 years ago!) However most of this testing was ad hoc, either requiring visual examination of the outputs, or simply testing current vs previous outputs. The RUnit (2005), svUnit (2009) and testthat (2009) packages brought more formal unit testing into R community.
Since releasing covr I have gotten a couple of requests to explain how it works. This post is adapted from a vignette I wrote to try and explain that.
Other coverage tools Prior to writing covr, there were a handful of coverage tools for R code. R-coverage by Karl Forner and testCoverage by Tom Taverner, Chris Campbell, Suchen Jin were the two I was most aware of.
R-coverage R-coverage provided a very robust solution by modifying the R source code to instrument the code for each call.