[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