在testthat中确定测试顺序是否可能？

Question

我正在使用testthat来检查我的程序包中的代码。其中一些测试是针对基本功能，如构造函数和访问器的。另一些测试则是针对在基本功能之上构建的复杂功能。如果基本测试失败，则预期复杂测试也会失败，因此没有继续测试的必要。

是否可以：

1. 确保先执行基本测试
2. 使测试失败引起测试过程停止

- sdgfsdh

Answer 1

回答你的问题，除非使用适当的字母数字命名你的test-*.R文件，否则我认为无法确定。

从testthat的源代码中，这是通过test_dir调用test_package的函数来获取测试的：

find_test_scripts <- function(path, filter = NULL, invert = FALSE, ...) {
  files <- dir(path, "^test.*\\.[rR]$", full.names = TRUE)

让复杂的任务先失败有什么问题呢？

- Jack Wasey

---

“出了什么问题？” 我的第一个想法是“计算时间”，寻找快速失败而不是长时间等待。（我的一个项目不可避免地需要15-20分钟才能通过所有测试。此外，我的测试之间存在依赖关系：一个测试设置环境，其他测试重用组件。在我的情况下，将测试分成多个文件很有用，尽管并非所有情况都适用。） - r2evans

说得好。如果这对你很重要，那么将测试分成几个部分并只运行其中一些是有技巧但也是可能的。运行特定的测试套件只需要一个命令行参数，但它与Rstudio完全不集成，在两个组之间共享测试内容或使用testthat可能都需要大量维护工作并且容易出错。因此，我同意你的观点！ - Jack Wasey

Answer 2

关于测试顺序，您可以使用 DESCRIPTION 文件中的 testthat 配置来确定测试顺序（按文件）- 正如文档所建议的那样

默认情况下，testthat 按字母顺序启动测试文件。如果您有一些比其他测试文件需要更长时间的测试文件，则这可能不是最佳顺序。理想情况下，应该首先启动较慢的文件，因为整个测试套件将至少花费与其最慢的测试文件相同的时间。您可以使用 DESCRIPTION 中的 Config/testthat/start-first 选项更改顺序。例如，testthat 目前具有：

Config/testthat/start-first: watcher, parallel*

文档

- Basil-texh

Answer 3

一个最近的开发是 testthat 的并行测试处理 这可能不适用于您的情况，因为听起来您的测试之间可能存在复杂的相互依赖。如果您可以隔离您的测试(我认为这通常是更常见的情况)，那么并行处理是一个很好的解决方案，因为它应该加速整个处理时间，而且可能在"缓慢"的测试完成前显示出"快速"的测试失败。

- Moohan