logoalt Hacker News

JanisErdmanisyesterday at 10:21 AM1 replyview on HN

To put it simply if you have a function f(ctx) = ctx.a + ctx.b it is hard to see what are the arguments producing the output. Which are the elements in the datastructure you need to vary in order to have exhaustive tests. Whereas if one refactors it as f(ctx) = g(ctx.a, ctx.b) you only need to test function g with respect to (a, b) whereas forwarding of methods can be simply covered in integration tests without any care whether function g is implemented correctly.

To make such testing strategy to work data structures need to be small. It is better to have multiple small data structures rather than one big universal one where methods are defined at the ctx level making exhaustive tests difficult.

Perhaps, I haven’t been clear. I agree with Pike’s advice strongly. What I am trying to say here is that the Perl’s rule 9 is diametrically opposite of what Pike says.


Replies

CyberDildonicsyesterday at 1:48 PM

To make such testing strategy to work data structures need to be small.

Why would that be true?

It is better to have multiple small data structures rather than one big universal one where methods are defined at the ctx level making exhaustive tests difficult.

I don't think you are backing this up at all, you just keep saying it over and over. It's also not even about big data structures it's about having fewer data structures and using them over and over. You can see where this is effective even in javascript and lua with their tables that have hash maps and arrays.