Agile Otter Blog

One day, a fish came to visit some kangaroos. He saw right away that the kangaroos spent all their time hopping on the dusty ground and browsing among the shrubs. Their habits would never work, and surely lead to their deaths, if they were to come to the ocean reefs even for a single month! "Foolish kangaroos," he called to them, "heed my words and live! This hopping and browsing is pointless madness! You must learn to paddle and snatch live prey from among the rocks! The ocean is no place for hopping air-breathing creatures, so come follow me and learn the better way!" The kangaroos, amazingly well-adapted to their un-ocean-ly environment, dutifully ignored the fish. They looked for common ground for conversation, but somehow the topic always turned to the futility of hopping and the unpleasantness of a dry environment. Sometimes they asked polite questions, and the patient among them tried to explain that their way of life was forever on solid ground whe...

Just for the record: it is flat out impossible to "do the tdd" after the code is finished. This is just a matter of definition. You can write tests after the code is finished, but that has no relationship to TDD whatsoever. None. Nada. Zip. In TDD you write a new, failing test. Next you write enough code to pass the test. Then you refactor. This repeats until the code is done, writing and running tests continually. It shapes the way the code is written. It is a technique for making sure you write the right code, and that you do so in an incremental and iterative way. In ATDD, you have a failing acceptance tests. You take the first failing tests (or the easiest) and use TDD to build the code so that that part of the AT passes. You run the AT after each major step that you've built using TDD. When the AT is all green, you have completed the feature. This helps avoid early stop and also helps avoid gold-plating. If tests were product, then it would make no difference...