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

[Neal Fultz]

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 using 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 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>
> > 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
> >
> >
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

	[[alternative HTML version deleted]]