Yes! You can handle this programmatically and automatically. Let me describe two ways in detail:
Implicitly using version numbers . This is an approach that Rcpp has been using for many years, and it is completely pedigree and is not dependent on any other package. Our tests start with the file in tests/ and then RUnit is passed, but this last part is an implementation detail.
In the main tests/doRUnit.R we do the following:
## force tests to be executed if in dev release which we define as ## having a sub-release, eg 0.9.15.5 is one whereas 0.9.16 is not if (length(strsplit(packageDescription("Rcpp")$Version, "\\.")[[1]]) > 3) { Sys.setenv("RunAllRcppTests"="yes") }
In essence, we check to see if the version is in the form of abcd - and if so, then this is the development version. This means run all tests. If the release version of the abc form goes into CRAN and fails to run these tests, because they will exceed their time limits.
In each of the actual unit test files, we can decide whether we want to comply with this variable and skip the test if it is installed, or execute in any case:
.runThisTest <- Sys.getenv("RunAllRcppTests") == "yes" if (.runThisTest) {
This mechanism is fully automated and independent of the user. (In the real version of the package, there is another if () tag that allows us to suppress tests, but these are the details that we do not need here).
I still like this approach.
Explicitly with the help of resource files. Another package that some of us are working on (recently a lot) requires a certain backend. Therefore, in the Rblpapi package, we test the existence of a file that my co-authors and I are each below our $HOME directory to configure credentials and connection details. If the file is missing, for example. on Travis CI or CRAN, or for other users, tests are skipped.
We decided to use the resource file as an R file; it displays it if found, and thereby sets the values ββfor options() . Thus, we can directly control whether to run tests or not.
#
Similar to the first use case, we can now set more variables that will be tested later.
Explicitly via Travis CI Another parameter that we use in rfoaas is to set the environment variable that controls this in the Travis CSR file :
env: global: - RunFOAASTests=yes
which tests the script then raises :
## Use the Travis / GitHub integrations as we set this ## environment variable to "yes" in .travis.yml ## ## Set this variable manually if you want to run the tests ## if (Sys.getenv("RunFOAASTests=yes") == "yes") runTests <- TRUE
In this case, I also set a switch based on my user ID, as I pretty much agree with this project:
## Also run the tests when building on Dirk box, even whem ## the environment variable is not set if (isTRUE(unname(Sys.info()["user"])=="edd")) runTests <- TRUE
Explicitly through another variable . Of course, you can also rely on another variable used in all of your packages. I think this is a bad idea. If you install this in your shell, work on package A and install it to suppress tests, but then switch to package B --- you will probably forget to disable the variable, and then you wonβt be able to check. I like this approach the least and do not use it.