In my understanding, anything put inside test_that() should be compartmentalized, meaning that if I load a package in test_that(), its functions and methods shouldn't be available in other test_that() calls.
In the example below, there are 3 (empty) tests:
- In the first one, we can see that the method
as.matrix.get_predictedis not available in the namespace. - In the second one, I load the package
insight, which provides the methodas.matrix.get_predicted. In my understanding, this method should only be available in thistest_that()call. - In the third one, we can see that the method is available.
library(testthat)
test_that("foo 1", {
print("as.matrix.get_predicted" %in% methods(as.matrix))
})
#> [1] FALSE
#> ── Skip (???): foo 1 ───────────────────────────────────────────────────────────
#> Reason: empty test
test_that("foo 2", {
invisible(insight::get_parameters)
})
#> ── Skip (???): foo 2 ───────────────────────────────────────────────────────────
#> Reason: empty test
test_that("foo 3", {
print("as.matrix.get_predicted" %in% methods(as.matrix))
})
#> [1] TRUE
#> ── Skip (???): foo 3 ───────────────────────────────────────────────────────────
#> Reason: empty test
Why is that? Are there some workarounds?
Edit: I'm looking for a solution specific to testthat, not another testing framework.
Too long for a comment, but reproducible. The test files are sourced in collation order, each in a new R process, hence the
librarycall intestB.Rdoes not cause the test intestC.Rto fail.This is the "vanilla" approach to compartmentalizing tests that many people still prefer over testthat and other frameworks, at least partly because it heeds the warning in
?detach:and therefore is significantly easier for experts to debug and reason about, but that is perhaps a controversial opinion these days ...