[R-pkg-devel] Is using global assignment in package tests allowed?
I believe, in base R, package tests scripts are run sequentially in clean sessions via R CMD BATCH. Test scripts can load packages, load data, etc, but the state is lost from script to script. Not sure about testthat tests / rstudio run tests button, because iirc it recursively loads other scripts from a shim within a single job. If I had to choose between writing a normal function, or a complicated function that works with testthat scoping, I'd opt for the normal one.
On Thu, Jan 27, 2022 at 8:25 AM James Pustejovsky <jepusto at gmail.com> 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? 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 at 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 at 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 at debian.org
[[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel