[R-pkg-devel] Problems with too much testing

[Hugh Parsonage]

My 2c is that if a package has actually tested something like that
(say, the ordering of a list's elements), then it is 100% likely that
a script out there depends on that behaviour too.  In other words, the
change is not inconsequential.  R users are in debt to package
developers but I think it behoves us to take special care not to
underestimate the work involved when a package's behaviour changes.

On Fri, 16 Apr 2021 at 20:09, Duncan Murdoch <murdoch.duncan using gmail.com> wrote:
>
> I'm updating the rgl package, and have come across the following problem.
>
> Some packages that depend on rgl and do careful testing are detecting
> inconsequential changes.  A typical case is the nat package, which has
> extensive testing, some of which comes down to checking results from rgl
> functions using testthat::is_equal().  I rewrote some parts of the rgl
> code, and so some rgl objects differ in irrelevant ways.  For example,
>
>    obj <- list(x = NULL)
>
> differs from
>
>    obj <- list()
>    obj[["x"]] <- NULL
>
> (the first is length 1, the second ends up with no entries).  All tests
> in rgl would be like
>
>    if (is.null(obj[["x"]])) ...
>
> so the tests evaluate the same, but testthat::is_equal() doesn't return
> TRUE, because the objects are different.
>
> Another example would be
>
>    obj <- list()
>    obj$a <- 1
>    obj$b <- 2
>
> which differs from
>
>    obj <- list()
>    obj$b <- 2
>    obj$a <- 1
>
> in the order of the components, but since rgl always accessed them by
> name, that makes no difference.
>
> So what I'm looking for is a strategy to hide internal implementation
> details.  (I'm using a compare_proxy() method now which standardizes the
> objects, but that seems very specific to testthat version 3.  I'd like
> ideas for something more robust.)
>
> Duncan Murdoch
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel