unit-testing - 我们如何测试构建 R 包时未公开的函数？

Question

我目前正在开发 graphical analysis package对于 R。我们正在尝试使用两个 Clean Code 的原则和 Test-Driven Development (TDD)。但是，我们遇到了一个概念问题。
如何测试未公开的功能？
考虑以下简化示例。 Outer()是我们在 package 中构建的函数，我们通过在 NAMESPACE 中列出它来向用户公开它。文件。 Inner()是一个简短的(~5 行)效用函数:

Outer <- function(...) {

  Inner <- function(...) {
    return(x)
  }

  return( Inner() )
}

我们的 package 中的大多数用户公开功能是短的、单一行为的集合 Inner()位于单个 Outer() 保护伞下的样式函数用户可以调用的函数。 Granova.ds.ggplot() 是一个例子。 Clean Code 极力提倡这样的模块化设计。 ，我们对结果非常满意。但是我们不知道如何为它构建单元测试，因为我们想要测试的函数在 Granova.ds.ggplot() 范围之外是不可访问的。给定我们如何设计它的功能。
我们想到了几个想法/解决方案:

测试应该只能访问公共(public) API。因为像 Inner() 这样的函数设计上不公开(它们没有在 NAMESPACE 中导出)，我们甚至不应该尝试测试它们。

哈德利·威克姆的 testthat package wiki说它支持使用 R CMD check 测试“非导出函数”工作流程。

如果一切都失败了，我们可以以某种方式手动破坏我们的Outer()。用于测试目的的函数

到目前为止，这些解决方案都没有奏效
解决方案 1 似乎是一种逃避。我们相信，特别是在 R 中，拥有一个调用各种简短、单一职责实用程序方法的顶级函数是明智的。无法测试这些方法似乎很愚蠢，就像有解决方案但我们还没有找到的东西类型一样。
解决方案 2 可能会起作用，但到目前为止我们还没有让它起作用。如果你尝试克隆 our repository ，然后采购 inst/dev.R相信你会在测试输出中发现找不到函数 InitializeGgplot() , 即使 said function在 granova.1w.ggplot() 的第 613-615 行中定义.同样，运行 R CMD check在终端似乎根本没有执行我们的任何测试。不过，这确实需要大量时间并向我们抛出侮辱性错误:-(
解决方案 3 在某种意义上是务实的，但与始终朝着项目目标状态前进的目标背道而驰。这对我们没有意义。
什么是理想的解决方案
理想情况下，我们正在寻找一种方法来利用像 testthat 这样的包。在我们编码时快速提供反馈，并允许我们测试像 Inner() 这样的函数存在于 Outer() 等函数中.更好的方法是不诉诸 R CMD check ，由于我们的某些函数的 3-d 复杂性，每次运行几乎需要整整一分钟。
那么，我们缺少什么？ TDD 实践是否应该允许在 R 中测试外部/内部样式设置？如果他们这样做，我们如何在开发我们的包时这样做？欢迎任何反馈，我会尽量回复任何不清楚的地方。
谢谢!

Answer 1

如果 Inner实现您想要测试的重要功能，我建议移动 Inner到顶层，但不导出它。通常，正是出于这个原因，我避免在其他函数中嵌套函数——它们很难测试。

您可以在开发期间使用通常的 testthat 功能进行测试，因为您可能只是在所有 R 代码中进行采购，而不用担心 namespace (至少我是这样开发的)。然后使用 R CMD check结合 test_package确保测试在构建时仍然有效 - test_packages在包命名空间中运行测试，以便他们可以测试非导出的函数。