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

[Duncan Murdoch]

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 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
>