[R-pkg-devel] Problems with too much testing
brodie gaslam
brod|e@g@@|@m @end|ng |rom y@hoo@com
Fri Apr 16 13:40:32 CEST 2021
An all.equal method? This might not work with 3rd edition though
(untested), and I'm not sure what method registration requirements
would exist for the user.
Best,
B.
On Friday, April 16, 2021, 6:09:24 AM EDT, 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
More information about the R-package-devel
mailing list