Let’s talk for a minute about "over-coding". Over-coding, when you’re a TDD’ist, is writing more code than you (intended to) have test to cover. But I will offer a few thoughts on this to non TDD’ers and TDD’ers alike.
Many people, pro-TDD and con- both, seem to think of TDD as the name for a collection or rigorous mechanical rules. TDD is a kind of jack-in-the-box, where you sit there and turn the handle, circle circle circle, and out pops perfect software.
This is unfortunate.
There’s a lot of "always" and "never" in these rulesets. A typical example, "Never over-code." "Always write a test before each line of code". There are similar rule-sounding statements like these all over the place.
Now, maybe I’m not a real TDD’er. But I have been learning, teaching, doing, coaching, and advocating for it a very long time, and here’s the thing:
I over-code all the time.
I also refactor on red, leave parts of my code with no automated tests, ignore coverage numbers, and hardly ever write "macrotests" like story or acceptance or integration tests. …
… I sometimes design way ahead of my code, and far away from it. I don’t bring "beginner’s mind". I rarely write a test I don’t think I know how to pass. I’ll put three assertions in the same test. I’ll use incomplete assertions. There’s prolly more.
So there’s two questions on the table here, an easy one and a hard one.
-
Easy: What do I do when I over-code?
-
Hard: What on earth am I claiming when I say I’m a hardcore TDD’er?
When I over-code, I go back and add the test(s) I didn’t write. Since there’s usually already tests right nearby, I’m just adding one or two more. It’s easy and it’s quick. I don’t feel guilt, I don’t apologize. I just fix it.
I am a human, not a machine. I am given to distraction, I’m given to excitement, I know my code pretty well. Sometimes I handle more cases than yet have code for. Other times I don’t.
It, literally, depends on my feelings and my judgment.
You might wonder, does this sometimes lead me astray?
What? Are you kidding?! In programming, everything we do sometimes leads us astray. I’ve been hoist by every rule petard I ever deployed.
There isn’t an algorithm for programming. There’s some substantial theoretical evidence that there never could be one, but in any case, there’s a bazillion failed cases from actual practice giving us all evidence that there isn’t one.
TDD isn’t a ruleset.
So if it isn’t a ruleset, what is TDD?
Beats all hell outta me.
I can’t tell you. I can only tell you what it means to me when I say "I am a hardcore TDD’er".
(And, allow me a snarky moment: every time I talk about TDD, even when I expressly state I’m talking about how I do it, people, pro-TDD and con-TDD, come out of the woodwork to tell me a) I’m wrong and b) it will never work. It’s why I don’t want to write a book about TDD.)
For me, FOR ME, test-driven development is a style of programming, carried out inside a set of conscious premises, in which I write lots of very small tests for most of the very small objects and methjods I write, doing this because I believe it lets me ship more value faster.
Let me call out those features real quick, and then let me close with statements to the pro-crowd and to the con-crowd both.
- I don’t do TDD for reasons of art, craftpersonship, patriotism, discipline, or any kind of purity whatsoever. I TDD because my TDD lets me ship more value faster, assuming only that the value depends on me changing code.
- Small tests, and small objects, and small methods, are of critical importance to my usage of TDD. I solve combinatorics by decomposition and reasoning, not by scaling tests ever larger.
- This takes place inside a framework of ideas about which I’m quite confident. Here’s an old video discussing them. (NB: I now call the "money" premise the "value" premise, and the "chaining" premise the "parts" premise.
Five Underplayed Premises Of TDD | Video | GeePawHill.org
Hey, it’s GeePaw! I’m here to tell you today about five underplayed premises of Test-Driven Development. These premises form the kind …
And I want to finish this with two statements, one for the pro-TDDers, and one for the con-TDDers.
Pro-TDDers: Please lay off declaiming these over-simple always-never hyper-didactic purposefully-poloarizing rules.
Con-TDDers: Please stop hating on TDD, or me, because some doofus said something stupid about it, or some other doofus who doesn’t even code has forced it on you. That’s not on me, and it’s not on TDD. You’re not mad at TDD, you’re mad at our stupid broken trade, and I am, too.
Does the GeePaw Blogcast add value?
If so, consider a monthly donation to help keep the content flowing. You can also subscribe for free to get weekly posts sent straight to your inbox. And to get more involved in the conversation, jump into the Camerata and start talking to other like-minded Change-Harvesters today.