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

Duncan Murdoch murdoch@dunc@n @end|ng |rom gm@||@com
Thu Jan 27 18:40:15 CET 2022


On 27/01/2022 12:11 p.m., Ben Bolker wrote:
> 
> 
> 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.)

Rather than just complaining, I'll try to offer some constructive 
advice.  The answer I just posted to this 9 year old question on 
StackOverflow probably won't help the original author, but maybe it's 
helpful to others:  https://stackoverflow.com/q/70702130/2554330 .

Though I don't use testthat enough to know if it will actually work.

Duncan Murdoch



More information about the R-package-devel mailing list