"Hence! home, you idle creatures, get you home:
Is this a holiday? What, know you not,
Being mechanical, you ought not walk
Upon a labouring day without the sign
Of your profession? Speak, what trade art thou?"
-- Shakespeare, Julius Caesar
Act I, Scene I, Lines 1-5
The Leap Year kata is interesting. The real trick to the kata is not the leap year algorithm. No, it is picking the test cases in such a way as to not cause you to have to write the whole thing at once.
Let us look at an implementation in Clojure.
We see that the key to picking test cases is to have an idea of the order in which you plan on writing your code. How so? In the first test case we pick leap years divisible by 400, then we pick non-leap years divisible by 100, then leap years divisible by 4, and then years which are not leap years.
Does setting up your test case with the algorithm in mind violate TDD? I say no. In fact I think Uncle Bob would say no.
TDD does not mean no architecture. TDD does not mean no forethought. No, TDD means no production code is written without a test and that only as much production code is written as what is needed to pass the current failing test.
In other words, TDD would want you to think about the leap year algorithm a head of time and pick test cases which will move along the algorithm.
