Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better documentation of helper and setup files #1638

Closed
jennybc opened this issue Jun 1, 2022 · 1 comment · Fixed by #1769
Closed

Better documentation of helper and setup files #1638

jennybc opened this issue Jun 1, 2022 · 1 comment · Fixed by #1769

Comments

@jennybc
Copy link
Member

jennybc commented Jun 1, 2022

Working on the testing chapter of R Packages has made me think that the "special files" of testthat are under-documented.

It's not very easy to find out that they exist or to get advice on how best to use them.

I suspect there should probably be a vignette for this.

As it stands, the only docs I find are here in a "Special files" section that appears in the help for test_file() and is inherited into the help for test_package()/test_local()/test_check():

https://testthat.r-lib.org/reference/test_file.html#special-files

Below I'm going to paste some material I originally wrote for the revision of the testing chapter of R Package, but that feels too detailed. Maybe it can be used in testthat.

@jennybc
Copy link
Member Author

jennybc commented Jun 1, 2022

Setup and teardown

Sometimes there is truly global test setup that would be impractical to build into every single test and that might be tailored for test execution in non-interactive or remote environments.

Examples:

  • Turning off behaviour aimed at an interactive user, such as messaging or
    writing to the clipboard.
  • Loading a credential for auth.
  • Setting up a cache folder.

Put such code in tests/testthat/setup.R.
In fact, any file in that directory whose name starts with "setup" is treated as a setup file.
Setup files are run by testthat before running whole test files.
Note that setup code is not run by devtools::load_all().

If any of your setup should be reversed after test execution, you should also include the necessary teardown code in setup.R.
We recommend maintaining teardown code alongside the setup code, in setup.R, because this makes it easier to ensure they stay in sync.
The artificial environment teardown_env() exists as a magical handle to use in withr::defer() and withr::local_*() / withr::with_*().
A legacy approach (which still works, but is no longer recommended) is to put teardown code in tests/testthat/teardown.R.

Here's a setup.R example from the reprex package, where we turn off clipboard and HTML preview functionality during testing:

op <- options(reprex.clipboard = FALSE, reprex.html_preview = FALSE)

withr::defer(options(op), teardown_env())

Since we are just modifying options here, we can be even more concise and use the pre-built function withr::local_options() and pass teardown_env() as the .local_envir:

withr::local_options(
  list(reprex.clipboard = FALSE, reprex.html_preview = FALSE),
  .local_envir = teardown_env()
)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants