Run all tests in a directorySource:
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
Path to directory containing tests.
NULL, only tests with file names matching this regular expression will be executed. Matching is performed on the file name after it's stripped of
Reporter to use to summarise output. Can be supplied as a string (e.g. "summary") or as an R6 object (e.g.
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
grepl()to control filtering.
Source helper files before running the tests? See
source_test_helpers()for more details.
TRUE, throw an error if any tests fail.
TRUE, throw an error if any tests generate warnings.
If these tests belong to a package, the name of the package.
Strategy to use for load package code:
There are two types of
.R file that have special behaviour:
Test files start with
testand are executed in alphabetical order.
Setup files start with
setupand 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.
There are two other types of special file that we no longer recommend using:
Helper files start with
helperand 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
teardownand are executed after the tests are run. Now we recommend interleave 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.