R包本地testthat测试切换工作目录失败，Travis环境正常

这种本地和CI环境测试结果不一致的问题确实挺让人挠头的，我帮你梳理下可能的原因和对应的解决办法：

• setwd()的全局副作用：setwd()是修改全局工作目录的操作，testthat在本地运行时的初始工作目录可能和你手动运行函数时不一样（比如RStudio默认会以当前打开文件的目录为工作目录，而CI环境是标准的包根目录），这就导致切换目录的逻辑在本地出错，但CI环境刚好匹配预期路径。
• 开发/安装环境的路径差异：你提到的system.file()调用，如果在本地开发阶段（包未安装），它可能返回空字符串，而CI环境是完整安装包后运行，能正确获取到extdata路径，这就造成了本地路径获取失败、CI成功的反差。
• 编译脚本的相对路径依赖：如果外部库的编译脚本（比如Makefile）用了相对路径，在不同的工作目录下解析出的实际路径会不一样，CI环境切换到extdata后路径正确，本地却因为初始目录不对导致相对路径指向错误位置。

1. 彻底抛弃setwd()，用绝对路径指定编译工作目录 #

修改全局工作目录是风险极高的操作，更好的方式是在执行编译命令时直接指定工作目录，比如用processx::run()或者system()的wd参数：

# 兼容开发和安装后的环境获取extdata路径
get_extdata_dir <- function() {
  if (requireNamespace("pkgload", quietly = TRUE)) {
    # 开发阶段：包根目录下的inst/extdata
    file.path(pkgload::pkg_path(), "inst", "extdata")
  } else {
    # 安装后：用system.file获取标准路径
    system.file("extdata", package = "your_package_name")
  }
}

extdata_dir <- get_extdata_dir()
stopifnot(dir.exists(extdata_dir)) # 确保路径存在，避免后续报错

# 执行编译命令（以make为例）
processx::run("make", wd = extdata_dir)
# 如果用base R的system函数
system("make", wait = TRUE, wd = extdata_dir)

2. 验证testthat的本地运行目录 #

你可以在测试代码中临时加入一行输出，看看本地和CI的工作目录差异：

test_that("编译外部库正常", {
  cat("当前工作目录：", getwd(), "\n")
  # 你的测试逻辑...
})

对比本地和CI的输出，就能快速定位是不是初始工作目录不一致导致的路径问题。

3. 修正编译脚本的路径依赖 #

如果外部库的编译脚本（比如Makefile）用了相对路径，要确保路径是相对于脚本自身所在目录的。比如在Makefile开头加入：

# 获取当前Makefile所在的绝对目录
CURDIR := $(dir $(abspath $(lastword $(MAKEFILE_LIST))))
# 后续所有文件路径都基于CURDIR拼接
SOURCE_FILE := $(CURDIR)/src/xxx.c

这样不管在哪个目录执行make，都能正确找到文件。

内容的提问来源于stack exchange，提问作者Garini