I think of my style of coding as "microtest TDD". That can be misleading for folks, so let’s take a walk over a few of the ideas, implicit and explicit, that make up the approach. First things first, bear the money premise in mind in all that follows, to wit: "I’m in this for the money." In the software trade, we make money by shipping more value faster. This is why I adopt these practices, because when I do them, […]
Microtest TDD: The Big Picture See Full Post
I use spikes, periods of code-changing activity that end with no pushes, all the time, at small scale and large, as a way to develop my path. It’s a vital technique, and it’s often underplayed, so let’s spend some time with it. What’s are spikes? A spike is a stretch of time I spend mucking about in code, and that stretch of time has one rule: "Do anything you want, because you can’t keep it." We originally used the term
An Intro to Spikes See Full Post
The “How I Work (Test-Driving Mix)” drew some questions and comment. How I Work (Test-Driving Mix) Here’s one: a respondent says, “If I write a lot of small tests and I change how a feature works, I have to change or throw out all those microtests, which is a lot of work.” (The respondent proposed an answer for this problem, and it’s not a bad one, but raises some other questions we might get to later.) The one-liner response: “For
The Cost of Changing Microtests See Full Post
