test_that — A brief review

July 15, 2011
By

(This article was first published on Mark M. Fredrickson, and kindly contributed to R-bloggers)

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.

To leave a comment for the author, please follow the link and comment on his blog: Mark M. Fredrickson.

R-bloggers.com offers daily e-mail updates about R news and tutorials on topics such as: visualization (ggplot2, Boxplots, maps, animation), programming (RStudio, Sweave, LaTeX, SQL, Eclipse, git, hadoop, Web Scraping) statistics (regression, PCA, time series, trading) and more...



If you got this far, why not subscribe for updates from the site? Choose your flavor: e-mail, twitter, RSS, or facebook...

Comments are closed.