test_that — A brief review

July 15, 2011
By

[This article was first published on Mark M. Fredrickson, 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.

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 their blog: Mark M. Fredrickson.

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.



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.

Search R-bloggers

Sponsors

Never miss an update!
Subscribe to R-bloggers to receive
e-mails with the latest R posts.
(You will not see this message again.)

Click here to close (This popup will not appear again)