Test Driven Development (TDD) has always been a hard sell in many companies I have worked with. The resistance would come from all possible directions. Developers worry about extra overhead, managers worry about delayed project schedule, and finance worry about increased cost. However, since David Heinemeier Hansson posted his controvertial post “TDD is dead. Long live testing” more than a month ago, an already heated topic just got a lot hotter. For example, it has sparked agile heavyweights Kent Beck, Martin Fowler and David to have a series of hangout sessions to discuss and understand each other’s view. These are great discussions with lots of history and knowledge embedded. I highly encourage everyone to at least read up on the summaries of each discussion whether you agree TDD is dead or not!
Throughout these conversations, I detected a common theme though. Whether the discussion is around test isolation or design damage; over testing or unit test runtime limit, the objections seem to be derived from observations or experiences of strict, or better dogmatic, execution of a believe. This reminds me how my son would insist something as universal truth because he has seen it once. It is very hard to convince someone otherwise of what they have seen or done. As someone specilized in software development methodologies and best practices, I have learned and still often remind myself the principles of Tai Chi. Water, one of the softest things on earth, will always erode away any type of rock in their way. Anything used in extreme can be harmful, be it a technique, methodology, medicine, or ideology.
This is also why I not only preach agile development, but also try to live an agile life. Life is a journey, we, as driver of our own lives, have to steer us out of trouble in order to reach the next stop. So, can we declare TDD as dead but still be an advocate for proper testing? Yes. Do we need to declare it as dead in order to make that point? I don’t think so. What’s your thought?