I have a team I’m working with of great tactical programmers. These guys take the craziest specs you’ve ever seen from clients and turn them into shit that actually works. Tactical programmers are great, they are needed in every organization. Nothing will get you to a deliverable better than a solid tactical programmer. One thing I’ve found with many tactical programmers– it’s almost a universal trait– they don’t often write tests.
It’s not that a tactical programmer will never write tests, it’s just not their focus. They are on the front lines, working, well, tactically. Tests are a strategic issue. To many tactical programmers, tests are not something that are necessary. To the tactical programmer, unit tests are this vague, unimportant, time-consuming thing that someone else tells you that you really should do if you want to have good dental health into your later years. They are not something you need to make this feature work, they are something someone else wants for some unimportant reason.
I’m not going to argue why testing is important. There are enough flies on that carcass. What I want to give, to my team of great tactical programmers, especially, is a concept about writing tests that will make it more palatable.1
Why Starting To Write Tests Sucks
The fundamental thing is this: The best way to actually accomplish testing is to start writing tests.
The problem is that you look at this huge codebase you’ve written without a single test, and you start feeling sick to your stomach and grumpy about your chair and angry at the fact that you’re coffee is too cold and you say “Screw that, I don’t have time for that stupid shit.”
So, what do you do? You write another feature, that adds more untested code to your codebase, that makes you even more sick to your stomach the next time you think about tests.
And before you know it, the only thing you actually know about tests is this: Those fucking things make me sick to my stomach!
The One-Dish Theory of Work
When I clean my house, I don’t start and say “I’m going to clean the house.” There’s too much to do, too much to even think about. I start in the kitchen– but I hate cleaning, so I can’t even think about the kitchen. When I clean my house, I start by going to the sink and washing, not everything in the sink, but one, single dish.
I tell myself, “I’m going to wash one dish and see where I go.”
The thing is, of course, that soaping the sponge, washing that dish, and putting it away requires a small amount of set-up. Thus, when I’m done washing that one dish, it’s much easier to wash just one more dish. I mean, I’m already there, and I’ve got the sponge in my hand.
Before I know it, all the dishes are washed, and the counter next to my sink is clean. Well, with one clean counter, it’s easier to clean off this other counter. I’ll just clean this one other counter.
Just Write One Test
That’s how a non-test writing, tactical programmer can think about writing tests. Just write one. Because here’s the thing: It’s not that bad. The reason it’s not that bad is that the best way to accomplish testing is to start writing tests.
Not all of the tests. Just one test.
The beauty of testing is that they work no matter how many you have. You don’t have to wait until you have time to go back and write tests for everything all at once. If you just start writing tests for the things you work on today, now, then it’s not such a big task. Don’t write tests for every class in your codebase, but write tests for this one, small class you’re working on today.
Write one test, for just this one method in this one, small class, that you are working on today. Tomorrow, write one test for what you’re working on then. Maybe write two if you’re feeling cheeky.
What you’ll find is that, as you write tests here and there, for just the thing you’re working on, it gets easier and easier. Very soon, you’ll say “Well, I was going to just write a test for just that one method, but since I’m here in the test class, it’ll only take me another 20 minutes to write tests for _all_ the methods, so I might as well.” By the time you have a few weeks to actually fill in the rest of the tests, it might only take a few days, because you’ve been doing it and are more familiar.
Just write one test. Just one. You can decide after you write that one whether you want to write another, but at least write one.
Today.
- This is not news for seasoned developers, I’m not saying that it’s new [↩]


