Literal Laws

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:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. 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):

T.I.N.O.

Post subtitle: Test-driven delay?

My friends, I am currently in the middle of a death march at work, and we have had to take the quickest, most direct route towards working code, while at the same time designing a solution that can be cleaned up later and not need widescale surgery later when certain project managers cease examining the internals of their rectums when they should be cleaning up their scrum boards.

The chunk of functionality we were missing four or five days ago was large. It involved several new classes, sending data to and from the UI and the database alike, and non-trivial domain logic. In short: it was my wet dream, minus the wet.

Under time pressure, we started from the top-downwards. We started by designing the data structures, a.k.a. DTOs, the UI needed to send down to us. From there, we wrote the method in the application layer that would handle the request. In doing so, we wrote how we wanted the method to look and what objects we wanted it to collaborate with. Most of these objects did not yet exist, so we created them, and through the magic of recursion, we let the design evolve organically.

The Coder’s Whiteboard

As I imagine you’re noticing by now, my Atwood-recommended posting schedule is roughly every Wednesday and Saturday. That is twice as much as my initial goal.

Let’s dish about that TDD animal. I would like to argue that this acronym should always stand for Test-Driven Development, and never Test-Driven Design.

Why am I even making a fuss over seemingly interchangeable terms? First, I don’t think development and design are interchangeable. Second, depending on your goal at the time, the choice of one versus the other can have an impact on productivity.