Hadley Wickham Kirill Müller Kevin Ushey karl-forner-quartz-bio Jim Hester Dirk Schumacher Neal Richardson Craig Citro Tomas Kalibera Peter Meilstrup Michał Bojanowski windelinckx Jeff Allen dkesh Karl Forner Jennifer (Jenny) Bryan brodieG James Harris Gábor Csárdi Jon Clayden Jonathan Will Beasley Alex Bertram Lincoln Mullen

See all contributors



Travis-CI Build Status AppVeyor Build Status Coverage Status CRAN version

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, testy, bacon and 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.

Instructions for using this package can be found in the Testing chapter of R packages.

Integration with R CMD check

If you're using testthat in a package, you should put your tests in tests/testthat. Each test file should start with test and end in .R or .r. To ensure R CMD check runs your tests, place the following code in tests/testthat.R:



Also make sure to add Suggests: testthat to your DESCRIPTION.