The Head Eats The Tail

From a thread on the XpMailingList, splintering from ObjectionsToWorkingTestFirst (the moral equivalent of ObjectionsToSocksFirstThenShoes...)

---

[from http://groups.yahoo.com/group/extremeprogramming/message/87964 ]

One colleague of mine insisted that if the test/code/refactor cycle was small enough, then it didn't matter whether the test or the code came first. I was never really able to convince myself that he was wrong, even though I /feel/ and have experienced for myself that writing the test first is better. -- JbRainsberger

---

I suspect that's how the SmallTalkers fell into TDD. The cycle got so small that they realized the test side was actually prepping the code side, instead of reacting to it.

Ward?

-- PhlIp

---

Wow. My reaction was *immediately* that he's wrong. The test is the design. If you write the code first, when do you do the design?? Seems to me that it doesn't matter how *small* the cycle is, you need to write the test first. I guess I'm just one of those freshly created zealots...

... even though I /feel/ and have experienced for myself that writing the test first is better.

If it's just a test, for assurance of "correctness" he might be right. But I see TestFirst and Test-Driven as a design activity.... You have to design first...

-- KayPentecost

The things we do in the past influence the things we do in the future, and not the reverse. Therefore if we write code first and then test, the code influences the test. Is that what we want? It's not what /I/ want. -- RonJeffries

---

From a right-brain perspective (DrawingOnTheArtistWithin), both the "design" and the "test" are descriptions of the whole solution. Some of us see a solution as a whole (even if vaguely) and then attempt to describe it. In my view, it makes little difference whether the description is labeled a "design" or a "test". Sometimes I code first and then test. When I do, I am comparing the code (and the test) to the design I already "see" in my head. Sometimes I test and then I code. When I do, I am comparing the test (and the code) to the design I already "see" in my head. The abstract "design" stands separate from either. Sometimes the design emerges from existing code. Sometimes the design emerges from existing tests. Both (design and tests) are necessary, and both are part of a cycle. TheHeadEatsTheTail.

If we're going to credit your "it makes little difference whether the description is labeled a "design" or a "test"." Then I read "Sometimes I code first and then test." as though the design comes from the code. That might be fine for the proverbial 100K monkeys but really, it's far more likely that you are coding with intent, i.e. with a design in mind (whether that design has been explicated or not). When coders give tech_docs its right value, the whole world will come right. Honest. Scouts' honour. I promise. --BenTremblay

---

I still say (as in my http://groups.yahoo.com/group/extremeprogramming/message/87988 post) that we lose something if we don't run the test before writing the code. A newly added test might succeed before we add the production code for several reasons:

1. It's an ineffective test. (Doesn't run. Doesn't test the right things. etc.)
2. The code has already more general than is necessary to cover the other existing tests.
3. This test is redundant. (Maybe it serves to improve our confidence or protect against some possible future error. But it isn't really needed, to justify today's code.)

If we write a test, intending for it to fail, but it does not... We may learn something.

-- JeffGrigg

Get the test to fail for the correct reason. -- PhlIp

Yes; quite true! When you write a test, you typically expect it to fail. Not only that, but you expect it to fail in some particularly well-defined way. If it fails in some other way... You may learn something. ;-> -- JeffGrigg

---

See TestDrivenDevelopment