One of the basic principles of testing is "test interface, not
implementation." Tests that violate this principle become "change detector
tests" instead of "correctness tests" and essentially prevent any
improvements to the code. In C++ objects have "public" and "private"
methods, and the testing
I'm generally in accord with Duncan on this. There are inevitably situations
where general
rules don't apply. Our challenge is to find practical ways to keep the overall
workload of
all participants in the process to a minimum.
JN
On 2021-04-16 10:18 a.m., Duncan Murdoch wrote:
> On 16/04/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
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 o
An offline message said
"Oh, you mean you're asking for an actual object-oriented language that
hides the internal representations of objects from users of a package.
Unfortunately for all of us, that isn't R."
Actually, I don't think that's what I want. We already have lots of
languages l
> On 16 Apr 2021, at 14:06, Duncan Murdoch wrote:
>
> On 16/04/2021 7:54 a.m., Hugh Parsonage wrote:
>> 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
On 16/04/2021 7:54 a.m., Hugh Parsonage wrote:
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.
I suspect this test is not intentional, and it really wouldn
On 16/04/2021 7:40 a.m., brodie gaslam wrote:
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.
It already has one, but it isn't used by testthat 3.
Duncan Murdoch
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 be
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
wrote:
I'm updating the rgl package, and have come across the
10 matches
Mail list logo
