To have a serious conversation about how to test, we have to start by considering what to test. As a microtesting TDD’er, what I want to test is our logic.
Enter the Money Premise
The money premise of TDD reminds us we’re in this for the money, that is, the primary purpose of TDD is to enable us to ship more value faster.
Deciding what is "value" is not a TDD task. The larger agility certainly asks us to make hard choices about value, but by the time we TDD those (always temporary & dynamic) decisions have already been made.
What I am saying is bold, and it will not surprise me if it surprises you, even if you already are a TDD advocate.
I am saying that there is no "change this code in a way that requires branching" task with scope bigger than half a day — in its entirety, in perpetuity — that we won’t do faster using microtested TDD, assuming you a) know how and b) have the TDD tool at the beginning. It absolutely does not matter why you or your team or your org has decided you need to change code in a way that involves branching. That matters to you, your team, or your org. It doesn’t matter to the assertion I am making.
More features? TDD can do that faster. fewer bugs? TDD can do that faster. Get this thing to alpha so we can see if anyone’s dumb enough to buy it? TDD can do that faster. See if complex variant X is performant? TDD can do that faster.
It’s not because TDD is the end-all and be-all of ll possible situations. It’s because TDD is the fastest current known technique for changing code in a branchful way, and all of those depend on changing code in a branchful way.
I reiterate: I am assuming a) you know how to do it, b) you have your rig ready to go at the start. Those certainly aren’t valid assumptions to make everywhere all the time. But why would you bother learning or setting up if you weren’t gonna get a payoff?
The payoff — I have theory galore, but I am not coming from theory here but from practice as a hardcore working geek — is that any code changing that requires even modest logic goes faster with TDD. We don’t care about what/why the value is in this code-changing context. We only care that it’s code-changing in a situation that requires us to combine logic.
Another way to say this: I am interested in TDD’ing any code we wrote that has a local mccabe complexity > 1. If you don’t know what mccabe complexity is, there’s a thing called google, but the short phrase is "number of possible paths through the code".
Many of us start a new language by learning how to print "hello world" to the screen. If it’s a console program, that’s a one-liner. In its entirety, it calls a library that is built in to your programming language. It has a local mccabe complexity of 1. There’s only one path through it. No branching, no logic, no nothing. It is basically an exercise in typing. I do not wish to test it.
Wait. That’s not right.
It’s not that I do not wish to test it. It’s that it’s cheaper for me to run the program and see if it says "hello world" using a device I call "my eyes" than it is to write a test, even if I know how to test & I have a rig. And because it has no branches and depends entirely on the system library in nearly every respect, I am happy to use my eyes one time and walk away.
(Aside:) Occasionally we confront situations where transitive mccabe complexity becomes important. Those situations inevitably involve mutable state, which is one reason we don’t like mutable state.)
Now I will run out of steam here in just a minute. But I want to complicate this picture a very tiny amount, and in so doing, we’ll move from just the money premise to the money premise plus the chain premise plus the steering premise. Spoze I sometimes want to print "hello world" and sometimes want to print "hi mom!". I have to branch. I have a condition — let’s say I have another library call coin(), like print, that returns heads or tails.
if( coin ) print "hello world";
else print "hi mom!";The first thing you note, the mccabe has gone to two. There are now two paths through the code. Second thing you note, we have our logic in the game now.
It is at this point that you realize you haven’t the slightest ability to easily capture the output of those print statements. (You have encountered, in fact, your first awkward collaboration.)
Enter the chain premise.
We stop testing the app and test a part of the app. We don’t really want to test print or coin at all. We know they work. (If they don’t work, we have bigger problems.)
We want to test our logic. We want to be sure we do the right thing on heads and the right thing on tails. So what if we just test our logic, and not test the whole thing? Uhmmmm, nothing. We got nothing. The fact of the matter is that those damned print statements are in there screwing up our ability to test just our logic.
Enter the steering premise.
What if those print statements were not intertwined with our logic that we want to test? Then we could use the chain premise to test just our logic, and to hell with testing a system library call.
The only way to do that is to change our code. Rearrange it so we first decide what to print — our logic — and then print it, a thing we trust works and can eyeball cheaply.
To test that logic separately we need it separate, in a function.
print greetings(coin);
String greetings( boolean flip )
{
if(flip) return "hello world";
else return "hi mom!";
}The tests we write are two, one for each local mccabe path through greeting.
We have steered our design. We took into account what we wanted to test — our logic — and we changed our code so that we could test it easily.
We started by considering what to microtest. We want to test our logic. We don’t want to test the app. We don’t want to test the library. We want to test the parts where we write code that branches, and we want to do it cheaply enough that it makes us ship value faster.
The money premise reminds us this is more value faster. The chain premise tells us to test parts rather than the whole. The steering premise tells us to change our code to make that possible.
There are other problems. And we have answers for them, too. But to start TDD, start there. You will go a very long way.
Money, Chain, Steering.