Microtest TDD: The Big Picture

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, I go faster.

In particular, I don’t do them out of a fondness for artistry, intellectual purity, common decency, perfectionism, or theory. I do them because they are the best way I’ve discovered, so far, to ship more value faster.

Next, though I call what I do "microtest TDD", that’s really a shorthand for a whole bundle of practices. A more accurate name would be something that captures, in the big picture, working in the smallest ready-to-ready steps I can formulate. That’s a lot of words, tho. 🙂

The practices include things that are "coding", and they also include things that are "collaborating". Professional software developers have to do both, all the time, freely intermixed. Strong pro’s do both of those well.

Some coding-centric practices I do: microtesting, refactoring, frequent commits, trunk-based development, spike-pathing, evolutionary development.

Some collaboration-centric practices I do: pairing, mobbing, haykumeer protocol, direct customer involvement, continuous integration, standups, retrospectives, pull and swarm.

I don’t pay much attention to the distinction: they’re all practices, and I employ all of them, and occasionally some outliers, too, in my efforts to find and implement ready-to-ready steps.

Next, I can divide my work into roughly two modes. Sometimes I am "path-finding", which means looking for sequences of smallest-ready-to-ready that get me what I want. Sometimes I am "path-following", which means actually implementing those sequences.

An easy way to distinguish: when I’m path-finding, I throw away way more typing than I commit. When I’m path-following, I commit way more typing than I throw away. There are borders between these, gray transition-y areas, but mostly I’m well inside one mode or the other.

I spend significantly more time path-finding than path-following. It is the hardest work I do, far harder than path-following. But it’s also, for me, the heart of the job.

Occasionally, with very small problems, the finding and the following are happening at the same time: I roll little tests I don’t know how to pass but I’m sure I can get to pass, and then I pass them. That’s hardly rare, but it’s not my most common case, either.

Next, I believe that my productivity is generally dominated by two terms of the production equation. 1) The internal quality of the code I start with. 2) The size of the steps. Correspondingly, I obsess with both of those concerns. 🙂

The two biggest terms in the production equation are "how skilled am I" and "how hard is the domain". But the thing is, both of those are out of my ready and direct control. Not that I can’t change them, but I can’t usually change them at a time-scale that matters.

But the next two biggest terms are internal quality and step-size. And those are far more directly controllable by me, so that’s where I give my attention.

The practices I use to keep internal quality high are primarily TDD in the narrow sense and refactoring in the narrow sense. My experience has been that my style of TDD almost forces a certain level of internal quality, and the refactoring either enables that or refines it.

And the step-size? Well, for that my main practice is what I call spike-pathing. It means that I use path-finding code-I-don’t-commit to discover the path-following code-I-commit.

So that odd rambling muse is it for now, but I see it as setting a context in which I can discuss in much greater detail, each of the practices, how I use them, and how they relate.

I have written or spoken at one time or another about nearly all of these practices. I intend to do so again, and to do so in greater depth, practice by practice.

In the meantime, though, since you so graciously read all the way to the end of this:


I love talking and thinking about this stuff, and if anything I’ve said here triggers your curiosity, well, ask me about it.

The GeePaw Podcast

If you love the GeePaw Podcast, show your support with a monthly donation to help keep the content flowing. Support GeePaw Here. You can also show your support by sending in voice messages to be included in the podcasts. These can be questions, comments, etc. Submit Voice Message Here.

Want new posts straight to your inbox once-a-week?

6 thoughts on “Microtest TDD: The Big Picture”

  1. Hello Geepaw,
    I love your content and insights on the geek trade. Thank you for all the advice.
    I have one question that I would like to ask you: You said here that you throw away more code than you commit when you are path-finding, and in your introduction to spikes you said it is because you want to find WHAT you should do, more than the HOW to code it.
    But there you said that you do a “git reset –hard” to throw away what you build, but why do you commit it, if you know you`re gonna throw it away?
    Wouldn’t it be easier to just not commit and just undo the changes?

    Thanks again for all your content.

    1. I’m not throwing away commits: git reset isn’t a revert, which is what we’d need if I committed my work. Reset in that form just restores the working directory to exactly where it was at when I last pulled.

      In general, I use git in the simplest possible way. My mission in life is to never become a git rockstar. For instance, I avoid all “cherry picking” behavior, where I choose what changes to keep and what ones to lose.

      I used to use “git checkout — .” (at root), but that only cleans up changes I’ve made to files that were already committed before. “git reset –hard” also eliminates all the additions. If I recall correctly, too, there’s some funny business with deletes and renames that checkout also messes up but reset doesn’t. git reset –hard just instantly resets me to the pull I started with.

      One more thing: I have an odd personal quirk: I do most of my git’ing at the command line instead of through the IDE. I realize that’s weird. It’s just that I’ve used many IDE’s and source vaults over the years, and have been burnt many times by IDE bugs. That’s not a recommended thing, it’s just an odd tic of mine. 🙂

      1. Thanks for the answer! I get it now.
        I don’t think git on the command line is weird. I know how to work it better on the command line than on IDEs.

        Thank for the answer again.

Comments are closed.

Scroll to Top