Testing R Code

Among various ways to test R code on GitHub / Travis / Codecov, there exist four main approaches:

1. use RUnit package
2. use testthat package
3. use one’s own custom function (what I’ve been doing so far)
4. save test output as reference & compare modified code output against it

After reading this post [http://yihui.name/en/2013/09/testing-r-packages/], I realized that saving reference values to compare against them the output after code is modified does not allow TDD, or test driven development. So the tests will always “drag behind” the development process.

I am currently using option #3. However, there are obvious shortcomings of this approach in large projects. Since I am using R as well as other languages, naturally, my choice falls on RUnit (xUnit framework) as multiple languages use this format and this fact will make life easier in the long run.

Key points about the testing workflow:

1. install the package
2. test the package
3. testing in development mode is a separate matter and won’t be my primary concern

File locations (using Dirk Eddelbuettel’s github repo as an example):

“package_root/tests” folder contains only the file “doRUnit.R” that launches tests {launcher example}

“package_root/inst/unitTests” contains a file with the primary testing suite builder code {suit_builder example} and test code files {test files examples}. “unitTests” folder will be moved into the package root folder after installation and will become accessible to the ‘laucher’ R code sitting in the “package_root/tests” folder.

References for RUnit:

• https://github.com/eddelbuettel/rcppgsl/blob/master/tests/doRUnit.R
• https://github.com/eddelbuettel/rcppgsl/blob/master/inst/unitTests/runTests.R
• https://github.com/RevolutionAnalytics/rhbase/tree/master/pkg/inst/unitTests
• bells & whistles: https://github.com/metacran/mason

PS: A good review of testing packages (pros, cons, usage):

• http://bioconductor.org/developers/unitTesting-guidelines/