[R-pkgs] testthat: version 0.3

Hadley Wickham hadley at rice.edu
Wed Sep 1 14:54:46 CEST 2010

# testthat

Testing your code is normally painful and boring. `testthat` tries to
make testing as fun as possible, so that you get a visceral
satisfaction from writing tests. Testing should be fun, not a drag, so
you do it all the time. To make that happen, `testthat`:

* Provides functions that make it easy to describe what you expect a
  function to do, including catching errors, warnings and messages.

* Easily integrates in your existing workflow, whether it's informal testing
  on the command line, building test suites or using R CMD check.

* Can re-run tests automatically as you change your code or tests.

* Displays test progress visually, showing a pass, fail or error for every
  expectation. If you're using the terminal, it'll even colour the output.

`testthat` draws inspiration from the xUnit family of testing
packages, as well from many of the innovative ruby testing libraries,
like [rspec](http://rspec.info/),
[bacon](http://github.com/chneukirchen/bacon) and
[cucumber](http://wiki.github.com/aslakhellesoy/cucumber/). I have
used what I think works for R, and abandoned what doesn't, creating a
testing environment that is philosophically centred in R.

Changes in version 0.3

* all expectations now have a shortcut form, so instead of
     expect_that(a, is_identical_to(b))
  you can do
     expect_identical(a, b)

* new shows_message and gives_warning expectations to test warnings and

* expect_that, equals, is_identical_to and is_equivalent to now have
  additional label argument which allows you to control the appearance of the
  text used for the expected object (for expect_that) and actual object (for
  all other functions) in failure messages. This is useful when you have loops
  that run tests as otherwise all the variable names are identical, and it's
  difficult to tell which iteration caused the failure.

* executing bare tests gives nicer output

* all expectations now give more information on failure to make it easier to
  track down the problem.

* test_file and test_dir now run in code in separate environment to avoid
  pollution of global environment. They also temporary change the working
  directory so tests can use relative paths.

* test_package makes it easier to run all tests in an installed package. Code
  run in this manner has access to non-exported functions and objects. If any
  errors or failures occur, test_package will throw an error, making it
  suitable for use with R CMD check.

Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University

More information about the R-packages mailing list