What I am getting at is that when one has such gigantic data structure there is no separation of concerns.
Anytime one has access to a database one has access to one large global data structure that one can access from anywhere is a program.
This same concept goes for one's global state in one's game if one is making a game.
You keep saying you believe it, but that is literally what a database is, game state manipulation, string manipulation, iterator algorithms, list comprehensions, range algorithms, image manipulations, etc. These are all instances where you use the same data structures over and over with as many algorithms and functions and you need.
What does that mean? This is all the kind of abstract programming advice that sounds nice until someone needs an example.
A narrow focus helps to test each individual unit in isolation from each other.
A function operating on a data structure is already a narrow focus.
It is true that a database appears to be a single datastructure with hundreds of methods from the users perspective
And also from a reality perspective because it's literally what a database is about.
However if you were to look into how a database is implemented you would get to see the composition of data structures, like btrees that are tested in isolation.
I don't know what point you're trying to make. Data structures should be tested? I don't think anyone is saying they shouldn't.
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.
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.
It is better to have one collection type and use it everywhere directly.
Some Java developers had a tendency to encapsulate collections in <Type>Manager classes that grant limited operations/access to the list type. In practice this doesn't really buy you anything and you could have had a regular List<Type> instead.