I made the claim that m-proof, the seemingly valueless dust that microtests give us, is actually gold. Not only that, but it’s gold whose working out clearly connects to the triple focus of our movement: the made, the making, and the maker.
Microtests prove that what the geek said is what the computer heard is what the geek wanted. How can such a low-seeming value really be gold? Let’s work it out, eh?
The gold of microtesting comes to us in two categories. First, there’s the artifact itself, the actual test. Second, there’s the impact of working in a way that is centered around using these artifacts to write code.
Which is more valuable, the artifacts — the microtests themselves — or the artifact-centricity — the complex interactions and behaviors, the approach, given to us by working in/with/around/through the microtests? Noobs routinely think it’s the artifact, and olbs routinely think it’s the artifact-centricity.
We see this over and over again. In fact, noobs overemphasizing artifact over process-through-artifact is one of the reasons TDD is so hard to get in to one’s head.
Okay, so consider the value of just having the artifacts. Imagine we have shipped a product. We rub a lamp, we wish for microtests, they cost us nothing and they simply appear next to our code base.
What have we got?
Wellll. They don’t prove the made thing was what our payers wanted, still less that it was what our payer-users wanted, and even still less that it will make us money.
And we’re done, we’re not changing any code, so they don’t give us a safety net, cuz there’s nothing at risk.
Curses. I have just argued that microtests as artifacts are completely worthless, they are exactly the dust we thought they might be, and not remotely gold at all.
If we’re already completely done with the product, they’re just so much used kleenex cluttering up our repo.
Oh wait, no. If we’re completely done with the product, who cares whether the repo is cluttered? The repo is also completely useless. We’ve got a binary in nexus, right? No point in keeping the source code around. "rm -rf *" all it took was a simple thought-experiment with a single starting premise, "spoze you’re already done".
We’ve dispensed with the microtests. Also the repo. Also the compiler. And the programming language. And the manuals. And stack overflow.
I’m not gonna keep goofin’ on this, i’m sure you get the point. We’ve eliminated all possible value inhering in the microtests "after the software is done". The gold, if there is any, must come "before the software is done".
Why even go this far with the silliness? Simple, really. The overwhelming majority of logical analysis, especially from newcomers, is about the value of TDD based on some variety of "after the software is done".
That’s what people mean when they say "if you get it right you don’t need TDD". Look, if you get it right, the software is done, isn’t it? I could be wrong, but my understanding is that once a thing is right, it is also done.
So, I fooled you, didn’t i? You thought we were gonna get right to the value, and here we’ve spun out again. Further, I now have to depart for a bit.
but . . .
but . . .
I promise I’ll be back, and we really will go straight to a list of the value provided, all of which occurs when we’re not done, and much of it occurs not from the microtests themselves but from the act of working with them.
(Q: can u call a second long intro still an intro? Are we allowed to have two intros? God. This spec is really hard to read.)
Have a strange mid-evening!