Thread by @GeePawHill

TDD Pro-Tip: Build cells -- logic nucleus on the inside, environment inputs & outputs on the outside, and a semi-permeable cell wall between the two.

the metaphor i'm proposing here is really about the nature of borders in code. prior to TDD, my grasp of this topic was driven largely by the great theory of object-orientation that began to emerge back in the '80s and came to dominate the modern s/w landscape.

as with so many aspects of the programming world, TDD as it has developed is shaping my understanding of this vital topic -- the nature of borders -- even as i practice it.

borders can be approached at first as impermeable walls around some precious thing. (that approach won't stand up, but go with me for a minute.)

what, then, in the case of code, is the precious thing the borders are enclosing?

in the modern synthesis, the precious thing inside the border is "change-enablement".

the border exists to separate areas where i change things easily from areas where i can't.

this would be a shocking statement to nearly all of the OO folks in the '80s, and to be honest, it'd prolly cause at least a great deal of nervousness and uncertainty if i said it to most programming theorists today.

better spend a minute on that, then.

programming computers for a living is changing code. this notion lies near the center of the movement we're all in, it's even codified in one of our founding texts, _Extreme Programming Explained: Embrace Change_. the idea's influence reaches every corner of the modern synthesis.

but the movement didn't invent that idea from whole cloth. many of those '80s ideas about OO that are still considered valid were already aimed there, they just weren't stated that way.

a lot of those are embedded in SOLID, which is the most widespread of the modern statements about how to do programming, so i'll use those terms as my illustration of this.

start with encapsulation, what most of SOLID is really talking about. the original view of encapsulation was that we do it to hide implementation details. why would we want to do such a thing?

simple: so we can change them when we want.

the modern statement of the LSP says derived classes must be entirely substitutable for their super classes w/o any clients knowing the difference. why would we care about such a thing?

simple: so we can change part of our code's behavior w/o changing all of it.

the ISP says client code should not have to depend on server code it does not need. eh? why would we care about that?

simple: anything we don't depend on is able to be changed without affecting us.

the DIP says we want to depend on abstractions, not concretions. why not?

you know the drill: cuz concretions change more often than abstractions, and we want to enable those changes to happen without affecting us.

i'm not gonna keep going, you get the drift. returning to the main theme, then:

we make borders a certain way because it makes it easier for us to change code on one side or the other, and our whole entire livelihood depends on changing code.

enter TDD. it doesn't disagree with SOLID principles (or their founding base), it actually thickens and extends them, tho it also changes their flavor a little, taking one from the more theoretical to the more hardheaded pragmatism of a working stiff.

if the borders drawn from SOLID are about enabling change, those same borders drawn from TDD are even *more* focused on change-enablement.

TDD morphs "change-enablement" a little, you see. because TDD says we have maximum change-enablement when we have the same attributes we loosely call SOLID *coupled* surrounded on all sides by perfect testability.

(aside: "perfect" in the prior sentence is a very large topic, and one that's dear to all persons pursuing TDD, but this thing is already too damned long, and we'll defer describing "perfect" for another day.)

all of this means that the nucleus in these cells i propose is a nucleus of *tested* *branching* *logic*. that is the precious thing on the inside.

what about the outside? what's outside that nucleus of tested branching logic? well. we can divide that into three parts. 1) inputs and outputs for the nucleus. 2) other cells. 3) everything else.

(for my poor victims who were following along in the far longer thread i just killed. hang tough. we are going to stop right here right now, and continue the other parts of this in other muses.

one more tweet, then we're outta here.

the *inside* nucleus is tested branching logic. the outside environment is a) the inputs & outputs to that logic and b) everything else. the cell-wall *boundary* is what lets outsides of type a in and keeps outsides of type b out.

we're not nearly done.

have a strange evening!