This function is the low-level workhorse that powers
test_package(). Generally, you should not call this function directly.
In particular, you are responsible for ensuring that the functions to test
are available in the test
env (e.g. via
test_dir( path, filter = NULL, reporter = NULL, env = NULL, ..., load_helpers = TRUE, stop_on_failure = TRUE, stop_on_warning = FALSE, wrap = lifecycle::deprecated(), package = NULL, load_package = c("none", "installed", "source") )
Path to directory containing tests.
Reporter to use to summarise output. Can be supplied
as a string (e.g. "summary") or as an R6 object
See Reporter for more details and a list of built-in reporters.
Environment in which to execute the tests. Expert use only.
Additional arguments passed to
Source helper files before running the tests?
If these tests belong to a package, the name of the package.
Strategy to use for load package code:
A list (invisibly) containing data about the test results.
There are two types of
.R file that have special behaviour:
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
for more details.
There are two other types of special file that we no longer recommend using:
Helper files start with
helper and are executed before tests are
run. They're also loaded by
devtools::load_all(), so there's no
real point to them and you should just put your helper code in
Teardown files start with
teardown and are executed after the tests
are run. Now we recommend interleave setup and cleanup code in
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.