Site icon R-bloggers

Unit tests for R packages

[This article was first published on R/Notes, and kindly contributed to R-bloggers]. (You can report issue about the content on this page here)
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.

Karl Broman has written a nice blog post to recommend writing unit tests for R packages. Here are a few more pointers on how to write these tests.

I was introduced to unit tests by Barret Schloerke, who asked me to write some for the network plotting functions that I have contributed to the GGally package. His request mentioned two packages that I had never used before:

Once both packages are installed, the basic logic of unit testing with testthat can be learnt from the “Testing” chapter in Hadley Wickham’s R Packages book. Reasons for writing unit tests in the first place are listed in Wickham’s article about testthat in the R Journal, and are well illustrated in Broman’s blog post.

How many tests lie ahead

At the very least, writing unit tests for a function means trying out every argument of that function, as well as every situation where the function sends back an error, message or warning. As a consequence, functions with many arguments and/or conditional statements will require many tests.

Furthermore, because the first thing that you will take away from writing these tests is a proper idea of the many mistakes that users might make while trying to use your function, writing tests will lead you to add some control flow statements to your code, which will in turn, lead to more tests.

Also note that although it is usually possible to write unit tests for every aspect of a function, it is not always the case:

The remarks above suggest that, if your code is made of lengthy functions with many optional arguments placed in “if/else” conditional statements, then you are looking at code that will require an extensive battery of unit tests to reach high coverage.

Computing tests coverage

A simple way to get started with unit tests is to use the examples of a function as the first set of tests, and then to calculate the percentage of code that gets tested – or “covered” – through these examples.

The covr package makes it very easy to calculate this percentage, thanks to its function_coverage and package_coverage functions. The former is well illustrated in Barret’s tests request, and the latter does not require any argument to compute the coverage percentage at the level of the entire package.

The function_coverage and package_coverage functions produce objects that can be passed to the zero_coverage function, which will list the lines of your code that are not getting tested. Even better, if you use zero_coverage from within RStudio, the lines will be shown using markers similar to those used by code diagnostics.

The coverage functions above are meant to help you add tests until every function in the package gets as close to full (100%) coverage as possible.

To leave a comment for the author, please follow the link and comment on their blog: R/Notes.

R-bloggers.com offers daily e-mail updates about R news and tutorials about learning R and many other topics. Click here if you're looking to post or find an R/data-science job.
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.