Research possibility to add local options to devtools::check()

[droomelotdegendt]

Context

To protect sensitive data and speed up development, our test suite skips database tests by default. These are switched on interactively in the console using R session options: options(test.run_snapshot = TRUE).

However, standard package checks (like devtools::check()) execute in an isolated, non-interactive background R process. Because these background checks run with a clean state, they do not read our active workspace options() or our .Rprofile.

Consequently, database-dependent tests will always be skipped during local package checks.

Questions to resolve

1. Is there a clean, native way to pass our testing toggles to the background check process?
2. Do we want database-dependent snapshot tests to run during devtools::check()?

Initial Research

1. Passing options/environment variables to background checks

• project-level .Renviron - doesn't work: devtools::check() executes tests inside a temporary folder, ignoring the project-level .Renviron (a user-level .Renviron might work, but probably not a good idea)
• add argument env_vars - works!: We can pass environment variables directly with devtools::check(env_vars = ...)
• RStudio Build Options: We can prepend environment variables (e.g.: --env-vars=TEST_RUN_SNAPSHOT=TRUE) to the "Check Package" parameteres in Project Options -> Build Tools

2. Extra problem: the global environment variable test_con

Even if we can run the tests in our background process, our helper function fetch_watina_connection() will stop the tests.

fetch_watina_connection <- function() {
  skip_if_not(
    exists("test_con", envir = .GlobalEnv),
    message = "No active database connection found..."
  )
  return(get("test_con", envir = .GlobalEnv))
}

This function expects an active test_con object inside .GlobalEnv. During a background check, this environment is empty.
How should we solve this?

• Option A - Keep them skipped: Accept that devtools::check() is strictly offline code testing without a database connection. Database tests are only run interactively via devtools::test().
• Option B - Automatic connection and teardown in setup.R: If check-specific environment variables are detected (e.g.: Sys.getenv("WATINA_RUN_SNAPSHOT") == "TRUE"), we can modify our setup file to automatically establish the connection in the background .GlobalEnv and cleanly close it (teardown_env()) when the check is finished.
• Option C - Find a way to detect the test_con variable?

Next Steps

• Decide whether database connectivity is desired during devtools::check().
• If yes, decide on a way to pass the necessary variables to devtools::check() (currently the option with env_vars seems the best solution)
• If yes, assure a watina connection is available in the background process (currently option B seems the best solution)
• Update the testing README.md and the CONTRIBUTING.md to document how to trigger checks with environment variables.

[falkmielke]

Just to mention a "poor person's solution" to store variables and settings: not everything has to go by "environment".
A rater persistent part of the package is the file system and package folder. And a possible way to store options in there is a good old ".ini" or ".conf" file.

I have been using configr (cran) for this with good experiences. It has functions to write.config and read.config. I would suggest to create a .ini text file with a default that comes in the package (alternatively a wrapper function which sets defaults if no appropriate config file is in the working directory).
In any working project, an actual config file can offer options to enable the database tests.

[droomelotdegendt]

He Falk! Thanks for the feedback! Just to make sure I understand correctly, is this suggestion targeted at replacing our general .Rprofile setup, or specifically at this issue (passing settings into devtools::check())?

Some context why we settled on .Roptions + options() setup:

• No git friction: The .Rprofile is static and unchanged in Git, while developers toggle options safely in their active R session console.
• Session safety: Options reset back to FALSE with every new R session, preventing heavy snapshot tests from running accidentally.
• Offline defaults: It ensure database tests are never run on Github Actions or CRAN by default.

If we use a persistent config file (like .ini), local changes create a risk of accidentally committing these to GIT and they would persist over sessions.

Were you thinking of using the .ini file as a local gitignored file for devtools::check(), or did you have a different workflow in mind?

[falkmielke]

With a local .ini, you actually have all the options. I cannot fully advise on which one fits here because I do not know how this behaves in a package setting (package installed to library, then loaded to a different workspace), and I have close to zero experience with devtools and the checks it runs.
Some ideas:

• I would tend to ship a low-load example config with the package, which may serve as a default or not (and added to .gitignore after creation so that you can change it locally without git friction).
• In addition, the function to load the config would initialize defaults (e.g. fewer tests performed) for settings which are not covered. Those could depend on database connection availability / online status.
• You could have a settings loader function which, after execution, overwrites/reverts all settings to the "don't test" value. This would effectively give you a one-time execution trigger. Other functions could change triggers back to the "heavy load testing" exception in certain situations.

Documentation must be provided, options should have instructive names, and config loaders should double-check file conflicts and file content to prevent mishaps, but all in all this is manageable.
Much simpler examples how I used this are here and here.

Edit: I would keep the .Rprofile for all possible purposes; just the testing part which it cannot handle might get special treatment with a config file; however, you can combine the two, chosing to use config only if it exists and fallback to .Rprofile and env, or the other way round.