We TDD because test-driven development is the best way we’ve devised so far to actually do that. TDD is about more value faster, and it’s not about anything else. Well, as soon as I say that, of course, I have to talk about some of the things it’s not about because they can be really confusing. And there’s a lot of misinformation out there on the internet.
The first thing TDD is not about is this. TDD is not about good citizenship. You are not immoral if you don’t TDD. You’re not not a good looker forwarder or a protector of the future. It’s not about citizenship. TDD isn’t even about raising the quality of your code. Now TDD very often does increase the quality of teams that aren’t doing it to begin with, but that’s actually neither here nor there, because TDD isn’t about that. TDD is about more value faster.
The other thing it’s not about? It’s not about art and it’s not about craftsmanship. It’s not about the excellence of our high standards. The reason we test drive is by test driving, we go faster. We put more value into the field faster than if we didn’t do TDD. And that is the money premise. We’re in this for the money.
It’s not an algorithm for coding because there isn’t an algorithm for coding. All of those steps and pieces and parts of TDD, in order to choose which one to apply when, I am constantly making individual human judgments. And just for the record, we’re pretty happy that there isn’t an algorithm for turning human words into code. That’s what we do for a living, right? We turn human words into actual running programs.
The day after there becomes an algorithm for doing that, me and you and everybody in this trade is going to be looking for jobs on the night shift at 7-Eleven, and a week after that we’re all going to be hiding in the rubble from Skynet.
So it’s actually a good thing that there’s no algorithm for code. But this premise tries to highlight the extent to which you are going to be required– if you’re doing TDD– you’re going to be required to make active, individualized judgments. The judgment premise says we are absolutely, routinely, every day, all the time happily reliant on individual humans using their individual best judgment to guide us through the process.
External quality is anything a user of your system could tell you about that system. Is it slow or is it fast? Does it handle all the cases correctly or only some of them? Does it stay up and running the whole time no matter what? These are all characteristics of external quality.
Internal quality, on the other hand, is things that you could only tell by studying the code. Internal quality is stuff like is the code scannable, readable, the factors that make it easy to change. Is it well-factored, broken into chunks that we can manage and change independently of each other? Is it well-tested? These are the sorts of things that go into making internal quality.
To circle back around again, you can trade external quality for productivity. In other words, if you don’t care that the screen runs kind of slow in this particular part of the program, then I can get done faster, which means I can produce more because I can spend more time on other things. And so on and so forth.
Internal quality doesn’t work that way. Why? Because the third most important factor in my daily output– given that the first two factors are one, how skilled am I, and two, how hard is the domain– the third most important factor, where do I start? And where do I start incorporates all those things we call internal quality.
So the correlation premise is very clear. It says that internal quality and productivity are correlated. They go up together and, sadly, they go down together. And that is the premise.
Well, the chain premise is telling us that we write tests such that mostly what they concentrate on is individual connections in that dependency chain. So if I have a bunch of things, A, B, C, D, and E, where A calls B, B calls C, and so on, what I focus on first is how to write tests that can prove that A works assuming B works, and B works assuming C works, and so on and so forth until I’ve covered the entire chain. When I do that, I get the cheapest test that will cover the most ground for me. And that is the chain premise.
| the middle we have things like that the capabilities of our geeks, things like the capability of our interpreters of the market to actually express those needs to us effectively, and so on and so forth. A lot of factors in play when we build new software.
The steerability principle says we use tests and testability as one of those factors all the way through development, just as we do the other factors. In other words, we are constantly considering questions of how am I going to test this, and how have I tested it so far? All the way through, from the very first line of code we write to the very last line of code that we write. And that is the steerability premise.
But inside TDD, they’re almost invisible to us. They’re the air we breathe. So when you go out there on the internet and you start studying TDD, you know, you’re studying people who have already stood inside those five premises. As a result, they hardly see them anymore. That means they don’t pay a lot of attention to explaining to them.
So when you get out there and you start looking into TDD, yes, by all means, pay attention to the techniques used by the people who are inside the ring of those premises. But remember, the premises are really what are binding us into this test-driven approach in the first place.
So now you’ve heard the five underplayed premises of test driven development. And I hope as you go out there on the net, you’ll bear them in mind.
I’m GeePaw, And I’m done. Thanks.