Transitioning to to TDD

On Friday I held a class on test driven development for the group of developers that will be expected to start developing using TDD soon. For many it will be their first experience with TDD.

I demonstrated how to do TDD in a live coding session where I rapidly added features to a web service application by cycling through the red-green-refactor process several times.

I think the concepts and practices were well understood by everyone and I’m hopeful that we’ll be successful in migrating from a non test-driven culture to a test-driven culture.

The questions after the coding session were mostly focused on how to test the existing code; the code that has low cohesion and high coupling; the stuff that’s hard to test.

How to start testing large, untested applications

I suggest the following approach:

1. rank application features by total cost of ownership by looking at how much time and money is spent fixing defects and handling customer support issues
2. look at upcoming feature requests and consider where the system needs to be changed

Start by testing the areas that cost the most to support and the areas that need to be changed significantly or frequently.

Choose black box tests that cover the visible features rather than the implementation details behind those features.

Use tools like WATIR or WATIN to assist with manual testing by using them to execute test setup while still using manual verification.

There is no silver bullet. Untested codebases are expensive to test. In general I think the best you can do is to control costs, focus on tests with the highest potential ROI, and ensure that new features are tested.