Three More Tells

A while back I talked about The Three Tells. They weren’t poker tells. Instead, it was tell them what you’re going to tell them, tell it to them, then tell them what you told them. I thought it was a good way to approach a presentation then, and I still think it is today. But that’s old news. Today I’m going to tell you about three different tells. The three tells of Test Driven Development (TDD).

You might be wondering how TDD is like a presentation. I’m going to tell you how TDD is just a different implementation of the same formula. Let me explain.

The 1st tell – Tell them what you’re going to tell them

The first thing you do in TDD is write a test. You expect it to fail, and it does. Nothing surprising there. But what you’re really doing is telling yourself, your team, and the compiler, how you expect things to work. You’re telling them what the code you’re going to write is going to do. You’re telling them how you expect the code to be used. How and when you expect it to fail. And if you do it really well, you’re telling the people who will eventually use the code why they want to use the code and how it will make things better for them.

The 2nd tell – Tell it to them

The next thing you do is write the code. You tell yourself, your team, and the compiler exactly how do to what you want to do. You make the tests pass. You go into as much detail as needed. You might outline it then fill in the details. You might take the most important path and write that first. You might do the obvious parts first since you know what you want to say. You might dive deep in one area first because that’s where you’re least clear. And just like working on a presentation, you do some refactoring and moving things around to make it flow better. Until you’ve got it down to where it does everything you want it to and nothing more.

The 3rd Tell – Tell them what you told them

Once you’ve got the code written and the tests you wrote originally passing, you keep running the tests. As your understanding of the domain grows and you make changes. As others make changes to the same domain and other domains. As your understanding of the input data grows. You keep running the tests and reminding yourself, your team, and the compiler what you wanted the code to do. Reminding yourself why the code does what it does and why you wanted it to do it that way.

There you have it. TDD is just another presentation. Where you tell them what you’re going to tell them through your tests. Where tell them what you want to tell them by writing the code that makes the tests pass. And where, finally, you tell them what you told them by running the tests over and over again on each change, making sure that they still pass.