Fundamental Rule of Test Driven Development (TDD)

a) "Isn't the fundamental rule of TDD to write no line of code except
in response to a failing test?"

The above quote was taken from a discussion elsewhere.

I agree with the statement, but I do so carefully.

I feel that the higher rule is something like:

b) "The fundamental rule of TDD is to specify /how/ to /use/ some
code and its /results/ before becoming involved with the
implemenation of that use."

To me they are significantly different.

(a) emphasizes a failing test.
(b) emphasizes a desired usage and results.


Why do I knit-pick over the sublties? Because in Maverick Development
I am concerned that the /reason/ for a practice be very clearly
present. With the reasons well known, then alternative approaches can
be applied to satisfy the reason. That is very important to me.