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

Duncan Murdoch murdoch@dunc@n @end|ng |rom gm@||@com
Fri Apr 16 16:18:10 CEST 2021

On 16/04/2021 9:49 a.m., J C Nash wrote:
> Another approach is to change the responsibility.
> My feeling is that tests in the TESTING package should be modifiable by the maintainer of
> the TESTED package, with both packages suspended if the two maintainers cannot agree. We
> need to be able to move forward when legacy behaviour is outdated or just plain wrong. Or,
> in the case that I find affects me, when improvements in iterative schemes change iterates
> slightly. My guess is that Duncan's example is a case in point.
> I doubt this will ever occur, as it doesn't seem to be the R way. However, I do know that
> improvements in methods are not going to CRAN in some cases.

In the cases I've been involved with the authors of the testing package 
have accepted suggested changes when I've made them:  I think that's 
also part of "the R way".  However, this takes time for both of us:  I 
need to understand what they are intending to test before I can suggest 
a change to it, and they need to understand my change before they can 
decide if it is acceptable, or whether further changes would also be 

Github helps a lot with this:  if the testing package is there, I can 
quickly reproduce the issue, produce a fix, and send it to the author, 
who can tweak it if I've set things up properly.

For the kinds of changes you're making, I suspect relaxing a tolerance 
would often be enough, though if you switch algorithms and record that 
in your results, the testing package may need to replace reference 
values.  I think I'd be uncomfortable doing that.

Duncan Murdoch

More information about the R-package-devel mailing list