my_3_rules_of_TDD.md

My 3 Rules of TDD (Experimental)

Here is my experimental version of the 3 rules of TDD:

1. You are not allowed to write any production code unless it is to make a failing unit test pass. (No modification here)
2. You are not allowed to write any more of a unit test than is sufficient to sufficiently test a single method. (Instead of just enough to get a failure)
3. You are not allowed to write any more production code than is sufficient to pass all tests for the one method. (To match the new Rule #2)

Reasons for Changes

First, while I really love the idea of TDD, and really believe it has power, it can be very tedious, stupid, silly, assinine, to only write enough test code to get a failure, especially when counting compilation errors as failures. But I get the point of the rule: to not bite off more than you can chew and don't overestimate how much you think you can chew. I can definitely chew more than what is necessary to merely get a failure. In fact, if I am following good design principles, I should be able to chew a whole method, because good design says my methods will be small and focused on doing one thing well.

Secondly, running along the same lines, writing only enough code to pass a single miniscule test can also end up being very tedious, stupid, silly, assinine. Often, you end up with silly functions that do nothing but return the expected value. Instead, I'd rather write the whole method at once. Again, if I'm following good design, this should not be a task I can't wrap my head around, because my methods would be short and sweet.

Caution

Although my revision of the rules are a bit looser, that doesn't mean you can swing all the way to the other end of the spectrum. I advise to push toward the more strict practice just up to where it starts to feel silly, then back off a micro-smidgen.

Code Coverage

There's two reasons you wouldn't have full coverage under TDD:

1. You wrote more code than was necessary to pass the tests. You got carried away. Delete some of that code. We don't want any of your untested, superfluous code here.
2. You are missing tests. Don't be lazy. Write the test first.

Really, under TDD, neither of these situations should occur. So you should always have 100% coverage if you are doing TDD right.

Okay, maybe there is a third reason: Legacy code base. Not your fault. Do the best you can. Good luck with that.