tdd pro-tip #5: "No, smaller." in TDD, almost without exception, we want everything: a test, a method, a class, a step, a file, really, almost everything, to be as small as it can be and still add value to what we're doing.
this is the most common gaping hole in the practice of the noob, and it's a constant obsession for the olb. but it's not just an old-timer's tic, like the way my lips purse when someone uses the word "enterprise". there's rationale here, deep rationale. let's poke at it.
we owe our entire trade to the invention of the transistor. a Core i7 quad-core cpu has about 700 million transistors in it. there are a couple of billion of them in an iPhone.
do you know what's great about transistors?
do you know what's great about transistors?
(for the lucky 10,000: a transistor is just an electronic switch. it's got a wire that runs through it, just like the light-switch on your wall, and just like that switch you can open/close the through-wire. ...
... unlike the wall-switch, a transistor has another wire coming in, that doesn't come out again on the other side. that extra wire plays exactly the same role as the mechanical flipper on your wall-switch: it opens/closes the through-wire.)
we had electronic switches before we had transistors, two different kinds, actually, vacuum tubes and relays, the latter of which is still used in lots of applications.
so why, given we had two other substitutes, what is so great about transistors?
they have no moving parts.
because they have no moving parts, we can make them incredibly tiny. we can make them very fast. we can do it cheaply. we can guarantee their stability.
now, they're simple. dead simple (as switches -- they get more complicated when we use them to do other weird analog things). but it doesn't matter, because we can throw literally billions of them at a problem.
they are so ridiculously cheap we can multiply them at will. because they're so stable they basically *never* break. a transistor only breaks when you literally crush it or literally fry it. that's pretty much it. you can't break one accidentally.
that's a very long extended metaphor, and i freely admit to having stretched it out a long time. the thing i need you to understand is that this absolutely ubiquitous thing is tiny, fast, stupid-simple, and rock-solid stable.
tiny, fast, plentiful, stupid-simple, dead-stable.
a TDD'er wants every element of her code and every aspect of her mechanic in making that code to have exactly those properties.
a TDD'er wants every element of her code and every aspect of her mechanic in making that code to have exactly those properties.
two cases. one each from code and from mechanic. first the code. here's a class from the kontentment project, and its test. gist.github.com/GeePawHill/bad…
that class is a Fragment. Fragments have the job of changing the stuff on the screen. inside a timed animation, and telling their caller when they're done. this particular one changes it by adding something.
isn't she a beauty?
isn't she a beauty?
she's a transistor. she's incredibly small, 40 lines including whitespace and java-noise. she's stupid-simple. and she's dead-stable.
the contentment app has been in development for a couple of hundred hours of my time. the underlying function here, adding stuff to the screen inside an animation step, has been through at least a half-dozen workings.
why oh why would i do such a thing, re-work that functionality so many times? because in every previous rev, it worked "-ish". it mostly worked until it didn't work.
i'd get some bug in the whole app. and i'd go in to try to figure out what was wrong. *mostly* what was wrong had nothing to do with Entrance's functionality. *mostly*. but i could not be sure. i didn't have tests, and i didn't have it so simple i could tell at a glance.
Entrance was not yet a 'transistor' for me. i couldn't just throw around a bunch Entrances and assume they would never be "the problem". so i kept pushing and pushing and pushing to get to that point.
the final piece of the puzzle was actually figuring out the responsibility of Fragment, the interface Entrance is implementing. once i got that, *all* the fragment impls became transistor-like.
i no longer have to look at Entrance's code when something seems to be entering oddly. because Entrance is a transistor. actual scripts have dozens or hundreds of entrances. they work every time, they're tested, they're stupid-simple and dead-stable.
Entrance is a transistor.
Entrance is a transistor.
what about an example from my mechanic, my practice, not a made thing but the making of it?
like most geeks, i divide my time in the code between "flail" and "flow". when i'm flailing, i am basically just doing some kind of romp around the code base, trying this, trying that, debugging here, println'ing there, running the stupid app a bunch of times.
i might be chasing down a problem, or trying out some new architectural concept, or just thinking thinking thinking, using whiteboard-as-code and code-as-whiteboard. what i am trying to do is get to a place where i know enough to flow.
when i'm flowing, i am working from head, i am adding a tiny test, passing that test, and pushing to head. rinse, lather, repeat.
it's visible in the commit log.
flail: nothing for 2-4 hours.
flow: 10-15 pushes in 2 hours.
flail: nothing for 2-4 hours.
flow: 10-15 pushes in 2 hours.
the difference between these modes? in flail mode i don't have any transistors to hook up. in flow mode, everything i'm doing is just one stupid-simple dead-stable step after another.
rename this, pull up that, invert that condition, initialize that variable when you declare it, extract method, change signature.
every one of those is a transistor to me. each one is just a little tiny perfectly grasped (often automated and nearly always at least computer-assisted) step. bam. bam. bam. bam. that's the sound the transistors make as i hook them together.
a TDD pro worries about getting the pieces she works with to be as small and straightforward as she can possibly make them.
she's going for the feel of a transistor. and she's going for that because once a thing is a transistor, she doesn't have to worry about it anymore. it can be combined with other transistors to do just what she wants, just when she wants it.
from some angles, it seems like all of TDD is just this act: take something that works-ish and make it into a transistor or a combination of transistors.
language fails. i cast for metaphors that might help, and that's why you hear me with the "no hard shots", now the transistors, the thinking knee, and so on.
part of me wants to apologize for not having that language all set to go. but the other part of me says, wait, what, how do we expect that language to just be there already? we just have to grope towards it, and that's why i write these.
your starter question, if you're shooting for pro-TDD style: keep asking every day all the time, how could i turn this thing into a tiny simple stable stupid thing so i can then use it over and over without ever having to reason about its internals?
"no, smaller," should be a kind of default first-choice opinion about everything you make and everything you do to make it.
have fun.
have fun.
for the hard of threading, here it is in blog form: "TDD Pro-Tip #5: No, Smaller". geepawhill.org/pro-tip-no-sma…
