Five Underplayed Premises Of TDD | Video

Part [part not set] of 9 in the series Underplayed Premises

Five Underplayed Premises Of Test-Driven Development (Transcript)

Hey, it’s GeePaw! I’m here to tell you today about five underplayed premises of Test-Driven Development. These premises form the kind of fundament under which almost all TDD proceeds. And when I say that I’m a TDDer, I almost always mean I am operating inside the little ring formed by these five test-driven development premises. Let’s check them out.

We’re In This For The Money

The first premise of TDD is what we call the money premise, and it goes like this. We’re in this for the money. I know, that seems like a strange thing to say, right? Well, what does it mean? We make money in software development through one means exactly, and just the one. And that is shipping more value faster. That’s how we do it. That’s where the money is in software.

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.

We Happily Rely On Individual Judgment

The second premise of TDD is the judgment premise, and it says we rely every day, all the time, on individual human judgment. You know, there’s a lot of folks out there who might try to convince you that test-driven development is a kind of an algorithm for coding. You just follow these steps in this order and you will get TDD.

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.

Internal Quality And Productivity Correlate Directly

Next up we have the correlation premise. The correlation premise says that internal quality and productivity are correlated. They go up together and they go down together. They have a direct relationship. Now to understand that, you need to know a little bit about what I mean when I say internal quality. Internal versus external.

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.

Test A Chain By Testing Its Links

The fourth premise is the premise we call the chaining premise, and it goes like this. The way to test a chain is to test each individual link in that chain. How does that work? Well, the idea is this. Our programs are always built out of smaller pieces and mid-sized pieces and then larger pieces. And there’s a chain. We call it a dependency chain.

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.

Tests & Testability Help Steer Design

Last but by no means least, we have the steering premise. The steering premise says that when we steer the development of our project all the way through, it tests and testability are first class participants in that process. So when we build new software, there are lots of different factors that we’re constantly balancing as we build it. On the one hand, you have things like the market and our expectations about where the market is going to go. And on the other hand, you have things about the actual technical capabilities of the particular platform that we’re running on.

| 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.

Why Underplayed?

So we have these five premises, right? The money premise, the judgment premise, the correlation premise, the chaining premise, and the steering premise. Why did I call them underplayed premises at the beginning? Well, there’s a reason for that. It’s because when you’re outside TDD, those premises are arguable, debatable, wranglable at length. And in fact, we all can do it.

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.