power of moderatioin

Does #TDD really need to be dead?

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?

6 thoughts to “Does #TDD really need to be dead?”

  1. Many folks tend to think that TDD is just enforcing the use of Unit Testing and it’s more profound. If you want to apply TDD you must also consider going agile and having an architecture and tools that foster its adoption.
    After years pursuing the adoption of Unit Testing and TDD I finally found SCRUM+BDD to be a very good pragmatic approach.

    Firstly, you must ensure that your functional requirements are translated into stories (As a **user**, I want to **action**, so I can **benefit**) and then break them down to engineering tasks. This way you make sure product owners evaluate stories in terms of benefits and you can link your test scenarios with stories from the begining and use specification by example to cover tasks and stories.

    Secondly, you need proper tools. It’s impossible to apply TDD or BDD without automation. If you work on Java platform, you can easily integrate jBehave and Helium in your projects, so you get BDD for both business and UI layers.

    At this point, you will have:
    1) your product teams writing scenarios and examples in plain text
    2) your test engineers coding unit testing clases to satisfy the clauses
    3) your developers builiding the minimum code to satisfy the changes and new features imposed by the new scenarios.

    I can assure that when you see this in action in a continuos integration environment you and your team will see a new dawn.

  2. I think you ve missed the main point of how to do TDD. Rather than zooming in which you don t want to do since you don t really know what the requirements are at that level, let your tests drive the interface design for collaborators which at this point will just be mock objects. In this way you can write those top level tests without the need to have most of your software implemented, and then move down a level and write tests for the mocked interfaces etc etc. In this way each interface you design is in direct response to the requests made from the level above.

  3. My main objection to TDD is that it is expensive. If you need to write tests for everything upfront, obviously your project will take more time or more developers to build it.

  4. My main objection to TDD is that it is expensive. If you need to write tests for everything upfront, obviously your project will take more time or more developers to build it.

Leave a Reply

Your email address will not be published. Required fields are marked *