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

[Ben Bolker]

On 1/27/22 12:07 PM, Duncan Murdoch wrote:
> 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

   Fair enough.

   As to Dirk's comments about not being required to use a particular 
test platform, I'll just say: inertia/sunk costs. I will definitely 
consider using tinytest, or something else, in future projects ... (I do 
like some of the extra features offered by testing platforms over the 
base-R/vanilla "source() everything in the tests/ directory" approach.)

   cheers
     Ben Bolker
> 
>>
>> 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