test_that — A brief review
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.
For the last month or so, I have been using the test_that unit testing package for R (a quick note on names: both testthat
and test_that
are used in the documentation. The library, as available from CRAN has no underscore, so use install.packages('testthat')
to get a copy). My free-time programming is always written a loosely TDD style, and I have rolled my own unit testing functions for R in the past, but they are not as polished as test_that
. For examples of my test cases using test_that
, see the RItools and optmatch repositories.
What attracted me to test_that
was the autotesting functionality. As code is updated, tests are automatically re-run and failures are reported. If tests are updated, only the test files are re-run saving a little time. I find R CMD Check
to be too slow for active development, and ad-hoc tests in the interactive session make me cringe. I can say that the autotest functionality in test_that
is as good as any I have used for Ruby or Clojure (well, I’d still like Growl notifications, but it’s not a deal breaker). To get the full advantage, I suggest creating a Makefile
in your project directory to handle starting up the autotest. Here is the Makefile from optmatch
.
local-install: rm -rf .local mkdir .local R CMD Install --library=.local . autotest: local-install R -q -e "library(optmatch, lib.loc = '.local')" \ -e "library(testthat)" \ -e "auto_test('./R', './inst/tests', 'summary')"
Then from the command line just type:
$ make autotest
To get the tests up and running.
While the package comes with functions for expressing many common expectations (e.g. expect_equal(a, b
), I was hoping to start writing my own expectation functions, but have not had the time to dig into the internals to see how these are implemented. In most cases I end up using expect_true
to evaluate a logical result, which works in most cases. There are two ways to write expectations: expect_equal(a, b)
or expect_that(a, is_equal(b))
. I tend to stick with the first as the second seems more verbose.
One last note: I had a little trouble integrating the test_that
style tests in to R CMD Check.
I found the devtools wiki to be helpful in this regard.
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.