[R-pkg-devel] Is using global assignment in package tests allowed?

On 27/01/2022 11:18 a.m., Ben Bolker wrote:

??? I will chime in briefly.

??? I have spent hours trying to understand the scoping behaviour of
testthat, mostly without success. I have lots of examples where I have
tests that fail *only* when running devtools::check(), but not when
running test_that in an interactive session, or in the same code run via
source() or in an R batch session.? So I am quite sympathetic to "beyond
my ken".

??? I agree that it's best to understand everything so that you can know
when you might run into trouble in the future, but I have sometimes
reconciled myself to giving up when it seemed I was spending much more
time debugging my tests than debugging the actual package code ...

??? For what it's worth, I have found that running <<- in these contexts
doesn't seem to bother CRAN at all -- possibly because it's the *tests*
that are potentially modifying the global environment, not the package
itself.

??? If you think about it, a prohibition on modifying the global
environment in tests would mean that a plain old test file that assigned
variables as part of testing flow would change the environment.

Yes, tests should be able to create variables, but they shouldn't go 
overboard.? A test like

 ?? x <- 1
 ?? stopifnot(x == 1)

will wipe out x, but that's probably not such a big deal.? On the other 
hand, a test like

 ?? c <<- function(...) stop('do not do this!')
 ?? testthat::expect_error(c(1))

is probably not a good idea.

Duncan Murdoch

On 1/27/22 10:56 AM, James Pustejovsky wrote:

But I am not using global variables at all in the package code (in
/R)---only for unit testing. Is this distinction relevant? Or do I 
need to
avoid global assignment even in the unit tests?

On Thu, Jan 27, 2022 at 9:40 AM Dirk Eddelbuettel <edd at debian.org> 
wrote:

On 27 January 2022 at 07:20, Jeff Newmiller wrote:
| I don't know the answer to your question, but "beyond my ken" doesn't
sound like a very convincing reason. Mucking with any environment that
isn't yours is asking for trouble... the behavior you depend on 
today may
come into conflict with the code you are coordinating with when you 
least
expect it.

Right on.

Yes a number of packages (of mine and other people) use a different
approach
to maintain 'global state' without ... using 'global variables' (== 
bad).

The trick is something like `pkgenv <- new.env()` in R/zzz.R and to 
then
also
set an option or two you need in .onLoad as eg  
`pkgenv[["prefence"]] <-
"foo"`
which you can later test for, alter, ... at will.

All without running afould of what `R CMD check --as-cran` may hate, 
all
the
while maintaining your logic flow.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

????[[alternative HTML version deleted]]