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

[Ben Bolker]

   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.

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 using 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 using debian.org
>>
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics