test_local() tests a local source package.
test_package() tests an installed package.
test_check() checks a package during R CMD check.
Tests live in tests/testthat.
test_package(package, reporter = check_reporter(), ...)test_check(package, reporter = check_reporter(), ...)
test_local(path = ".", reporter = NULL, ..., load_package = "source")
A list (invisibly) containing data about the test results.
If these tests belong to a package, the name of the package.
Reporter to use to summarise output. Can be supplied
as a string (e.g. "summary") or as an R6 object
(e.g. SummaryReporter$new()).
See Reporter for more details and a list of built-in reporters.
Additional arguments passed to test_dir()
Path to directory containing tests.
Strategy to use for load package code:
"none", the default, doesn't load the package.
"installed", uses library() to load an installed package.
"source", uses pkgload::load_all() to a source package.
To configure the arguments passed to load_all(), add this
field in your DESCRIPTION file:
Config/testthat/load-all: list(export_all = FALSE, helpers = FALSE)
To run testthat automatically from R CMD check, make sure you have
a tests/testthat.R that contains:
library(testthat)
library(yourpackage)test_check("yourpackage")
Certain .R files have special significance in testthat:
Test files start with test and are executed in alphabetical order.
Setup files start with setup and are executed before tests. If
clean up is needed after all tests have been run, you can use
withr::defer(clean_up(), teardown_env()). See vignette("test-fixtures")
for more details.
Helper files start with helper and are executed before tests are
run and, unlike setup files, are also loaded by devtools::load_all().
Helper files can be necessary for side-effect-y code that you need to run
when developing the package interactively. It's certainly possible to
define custom test utilities in a helper file, but they can usually be
defined below R/, just like any other internal function.
There is another type of special file that we no longer recommend using:
Teardown files start with teardown and are executed after the tests
are run. Now we recommend interleaving setup and cleanup code in setup-
files, making it easier to check that you automatically clean up every
mess that you make.
All other files are ignored by testthat.
Each test is run in a clean environment to keep tests as isolated as possible. For package tests, that environment that inherits from the package's namespace environment, so that tests can access internal functions and objects.