My friends, the code gods were watching me last week and filled me with the providence to contemplate test-driven development at just the right time to prepare me for an inter-team bru-ha-ha. The clarity I gained from T.I.N.O. was put to immediate use when explaining to another team why we don’t practice TDD exactly. Objects, I posited, and still posit, are best designed wholistically, because objects rarely exist in a vacuum.
That is the party line here on the Excellence In Programming web-ring, but that doesn’t mean we move on. No. Of course not. Let’s assume that we are total believers in dogmatic, hardcore TDD. That means we follow the three laws:
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
We are about to write a little service class that retrieves a data structure from the database, but we will strictly follow the three laws. Pay close, special attention to law #3. I want to see if I can arrive at the same code following these laws, especially law #3, as I normally do by my wholistic, top-down, design-by-code method.
First the test (law #2):