November 2018

This entry is part [part not set] of 3 in the series The Gold of Microtests

Okay, twice now i’ve intro’d this question about the value of m-proof, the rather trivial proof microtests give: what the geek said is what the computer heard is what the geek wanted. Time to just deal with it, eh? Remember that all of the value that comes from microtests comes before we’re done with the program. As we’ll see, some of it comes from the fact that the artifacts — the microtests — exist at all, and some of it […]

This entry is part [part not set] of 3 in the series The Gold of Microtests

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

This entry is part [part not set] of 3 in the series The Gold of Microtests

Okay, shall we take a breather from difficult concepts and do something at least a little more concrete and geeky? And the windswept trees whisper "yessssss, yessssss". Recall that a microtest is a tiny snippet of test code, run in a separate app, that depends on a tiny snippet of shipping code. It is typically focused in its intent on a single branch or calculation in that shipping code. It is fast to write, to read, to diagnose. What does