If you’ve been here a few times you might get the impression that I’m a fan of T.D.D. Certain things like the fact that I’ve created a project devoted to Test Driven Design, or the fact that I go as far as foregoing the T.D.D. maiden name in favor of its newer alias B.D.D., or even the fact that all I can talk about when I’m drunk is using interfaces and abstract classes with JUnit may give you the idea that I think of the practice as more than just a practice. Yes, lady and gentlemen… I believe in Test Driven Design. I believe in it so much that I’ve substituted it for one of my three daily square meals. I sleep under JUnit bedsheets with little green frogs colored on them. I even used T.D.D. brand peanut butter on my sandwiches. But… BUT!!! I don’t care about test coverage. That’s right. I don’t care if 30, 60, or 90 percent of my code is covered with unit tests. I’ve run the clover plug in for Maven in the past and while the generated report looks cool I could care less for what’s tested and what’s not.
I’m not hypocritical at all. I don’t write tests for the coverage. I don’t write tests to prevent bugs. I don’t write tests because my leadership wants me to. None of that means anything to me. Many people use one or more of these reasons for pursuing unit test development but I’m here to tell you these are all the wrong reasons. If you find yourself obsessing over test coverage then your doing yourself and your project a dis-service. If you primarily want to find and trap with your test suite then your suite is garbage. There is only one reason to write unit tests, my friend (We are still friends, aren’t we?) And that reason is for the interfaces. Don’t get me wrong, those other reasons are good things to have on a project but none of them is nearly as important as usable interfaces.
I’m writing tonight because those former reasons listed above are actually becoming my pet-peeves. People using them for writing tests completely miss the point. There are two types of unit testing. There’s Test Driven Design and then there’s Testing While Designing (TWD). TWD is probably the more popular approach and has tons of developers confused and fighting with the technologies. When you do TWD you end up with the very crippled and highly coupled design the TDD is supposed to alleviate. You also end up with very brittle tests that fast fall out of date with the corresponding source. When you practice T.D.D. your tests are never out of date because they precede or drive every bit of code you write. So as I already said, test coverage becomes irrelevant. It’s a given. A bonus. A perk. A consolation prize. It’s the toy wrapped in the plastic baggy sitting in the bottom of your Cheerios. The spare tire in your trunk. You know you need it but you don’t go all, “you gotta see my new Car! Mileage per gallon? I dunno, but check it out. It has a fifth tire tucked in my trunk” You… just… don’t… think… about… it. Who cares?
You don’t go looking to maximize test coverage when you do T.D.D. any more than you go looking to put a white wall or a mag rim on that fifth tire. I’m just a little worked up tonight because that’s the attitude I’ve seen in some people lately. I won’t name any names but I’ve heard some podcasts trying to explain the benefits of T.D.D. and I’ve seen other developers make speeches about recent projects with test coverage being one of the highlights. It’s starting to really get my goat. I don’t like when things get my goat… because it’s MY GOAT. Go get your own goat. Why you gotta be all on my mountain, jacking my four legged pet???!! If you can’t get a goat go sheep herding. I don’t care whatever! Just leave my goat where it is. I don’t come in your neck of the woods messing with your livestock do I? What was I talking about anyway? Oh yeah! Goats! I gotta get some shut eye… Holla if ya’ feelin’ me…