跳过CRAN上的测试，但在本地运行 [英] Skip tests on CRAN, but run locally

问题描述

如果通过CRAN测试了软件包，是否有一种简单的方法可以跳过软件包中某些测试的执行?背景是，我喜欢进行很多测试，总而言之，它们很耗时(不适用于CRAN).

It there an easy way to skip the execution of some tests in a package if the package is tested by CRAN? The background is, I like to have a lot of tests and in sum they are time consuming (not good for CRAN).

我知道有testthat::skip_on_cran()，但是我不想使用软件包testthat来避免其他依赖.我正在寻找一种模仿testthat::skip_on_cran的el-cheapo方法.

I know there is testthat::skip_on_cran() but I do not want to use package testthat to avoid another dependency. I am looking for an el-cheapo way to mimic testthat::skip_on_cran.

理想情况下，我想在目录pkg/tests中有一个测试文件，该文件可以调用测试(测试文件)，并且可以区分是否使用cran:

Ideally, I would like to have a testfile in directory pkg/tests that calls the tests (testfiles) and distuingishes if we are on cran or not:

if (!on_cran) {
 ## these tests are run only locally/when not on CRAN
 # run test 1 (e.g. source a file with a test)
 # run test 2
}
# run test 3 - always

推荐答案

是的！您可以通过编程方式自动处理此问题.让我详细介绍两种设置方法:

Yes! You can handle of this programmatically and automatically. Let me detail two ways I've set up:

隐式地通过版本号:这是Rcpp在很多年内采用的方法，它是完全通用的，并且不依赖于任何其他软件包.我们的测试从tests/中的文件开始，然后移交给RUnit，但最后一部分是实现细节.

Implicitly via version numbers: This is the approach taken by Rcpp for many years now, and it is entirely generic and not dependent on any other package. Our tests start from a file in tests/ and then hand over to RUnit, but that last part is an implementation detail.

在主文件中 tests/doRUnit.R 我们这样做:

In the main file tests/doRUnit.R we do this:

## 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")
}

本质上，我们测试版本是否为a.b.c.d形式-如果是，则得出结论，它是开发版本.这意味着运行所有测试".而a.b.c格式的发行版将转到CRAN，并且不会运行这些测试，因为它们将超过其时间限制.

In essence, we test if the version is of the form a.b.c.d -- and if so conclude that it is a development version. This implies "run all tests". Whereas a release version of the form a.b.c would go to CRAN, and not run these tests as they would exceed their time limit.

在每个实际单位中测试文件，然后我们可以决定是否要使用该变量并跳过测试(如果已设置)，或者仍然执行:

In each of the actual unit test files, we can then decide if we want to honour the variable and skip the test if set, or execute anyway:

.runThisTest <- Sys.getenv("RunAllRcppTests") == "yes"

if (.runThisTest) {

   ## code here that contains the tests

}

此机制是全自动的，并且不依赖于用户. (在实际的软件包版本中，还包装了另一个if ()测试，使我们可以取消测试，但这是我们不需要的详细信息.)

This mechanism is fully automatic, and does not depend on the user. (In the actual package version there is another if () test wrapped in there which allows us to suppress the tests, but that is a detail we do not need here).

我仍然很喜欢这种方法.

I still like this approach a lot.

明确地通过资源文件.我们中的一些人(最近很多)正在使用另一个软件包，它要求特定的后端可用.因此，在Rblpapi程序包中，我们测试文件的存在性，我和我的合著者都在我们的$HOME目录下，以设置凭证和连接详细信息.如果文件丢失---例如在Travis CI，CRAN或其他用户上，测试将被跳过.

Explicitly via resource files Another package a few of us work on (a lot lately) requires a particular backend to be available. So in the Rblpapi package we tests for presence of a file which my coauthors and I each have below our $HOME directory in order to set up credentials and connection details. If the file is missing --- as e.g. on Travis CI, or CRAN, or for other users, the tests are skipped.

我们选择将资源文件用作R文件；它如果找到它就提供源，从而为options()设置值.这样，我们可以直接控制是否启动测试.

We chose to use the resource file as R file; it sources it if found and thereby sets values for options(). That way we can control directly whether to launch tests or not.

## We need to source an extra parameter file to support a Bloomberg connection
## For live sessions, we use ~/.Rprofile but that file is not read by R CMD check
## The file basically just calls options() and sets options as needed for blpHost,
## blpPort, blpAutoConnect (to ensure blpConnect() is called on package load) and,
## as tested for below, blpUnitTests.
connectionParameterFile <- "~/.R/rblpapiOptions.R"
if (file.exists(connectionParameterFile)) source(connectionParameterFile)

## if an option is set, we run tests. otherwise we don't.
## recall that we DO need a working Bloomberg connection...
if (getOption("blpUnitTests", FALSE)) {

    ## ... more stuff here which sets things up

}

类似于第一个用例，我们现在可以设置更多变量，稍后再进行测试.

Similarly to the first use case we can now set more variables which are later tested.

通过Travis CI明确:我们在rfoaas中使用的另一个选项是在

Explicitly via Travis CI Another option we use in rfoaas is to set the environment variable governing this in the Travis CI file:

env:
  global:
    - RunFOAASTests=yes

测试脚本然后开始:

## 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

在那种情况下，我还根据用户ID设置了切换，因为我几乎是该项目的唯一贡献者:

In that case I also set the toggle based on my userid as I am pretty much to sole contributor to that project:

## Also run the tests when building on Dirk's box, even whem
## the environment variable is not set
if (isTRUE(unname(Sys.info()["user"])=="edd")) runTests <- TRUE

明确地通过另一个变量当然，您也可以依赖在所有软件包中使用的另一个变量.我发现这不是一个好主意.如果在外壳程序中进行设置，请使用程序包A并将其设置为禁止测试，然后切换到程序包B ---您可能会忘记取消设置变量然后无法测试.我最不喜欢这种方法，并且不使用它.

Explicitly via another variable You can of course also rely on another variable you use across all your packages. I find that to be a bad idea. If you set this in your shell, work on package A and set it to suppress tests but then switch to package B --- you will likely forget to unset the variable and then fail to test. I like this approach the least and do not use it.

这篇关于跳过CRAN上的测试，但在本地运行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！