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

[Duncan Murdoch]

On 27/01/2022 11:24 a.m., James Pustejovsky wrote:
> I suppose, but this seems like kind of a far-fetched possibility if 
> you're following any sort of reasonable scripting/development practices. 
> Why in the world would someone be working with extremely valuable data 
> and then decide to run all my package's unit tests interactively in the 
> same session?

Perhaps "extremely" was an exaggeration, but it's not that far-fetched 
for someone to notice a problem in your package and want to make a 
change and test it.

Your first test stomps on oswald2013, V, mod_A, mod_B, mod_C1, and about 
20 other variables.  That seems kind of excessive to me.

Duncan Murdoch

> 
> In any case, it sounds like I should either just skip these unit tests 
> or try to figure out what the heck is causing my namespace problems with 
> testthat.
> 
> On Thu, Jan 27, 2022 at 10:11 AM Duncan Murdoch 
> <murdoch.duncan using gmail.com <mailto:murdoch.duncan using gmail.com>> wrote:
> 
>     On 27/01/2022 10:56 a.m., 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?
> 
>     CRAN may let you do what you are doing, but as Dirk and Jeff said, it
>     could come back to bite you later.  For example, you may create a
>     variable named foo containing extremely valuable data, and then run
>     your
>     test.  (Tests can be run outside of R CMD check.)  If your test stomps
>     on foo, you'll lose all that data.
> 
>     It's worth using some trick like Dirk's to avoid this possibility.
> 
>     Duncan Murdoch
>      >
>      > On Thu, Jan 27, 2022 at 9:40 AM Dirk Eddelbuettel <edd using debian.org
>     <mailto: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 <https://dirk.eddelbuettel.com> |
>     @eddelbuettel | edd using debian.org <mailto:edd using debian.org>
>      >>
>      >
>      >       [[alternative HTML version deleted]]
>      >
>      > ______________________________________________
>      > R-package-devel using r-project.org
>     <mailto:R-package-devel using r-project.org> mailing list
>      > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>     <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
>