Many teams are moving to test driven development and very often this a good thing. In a drive towards increased code stability and maintainability, good test cases can be very helpful. But this is not always the case; while working with development teams, most teams seem to have one or more critical problems. It seems that it is easy to do Test Driven Development (TDD) badly – below are five situations that I have seen multiple times.

1. The Drive for Code Coverage

One of the teams that I worked with had been effectively outsourcing development. As a metric towards doing effective development they focused on making sure that they had high code coverage. While this was a good goal, a number of their developers wrote test cases which just called the new code to execute it and then did not do anything with the results. The test cases would all end with ‘Assert(true)’ and therefore would always have passing test cases.

2. The Absence of User Feedback

A software system with plenty of unit tests is generally considered to be well tested. But it is often all too easy to ignore what is being tested. In TDD the unit tests only point to specific potential problem areas in the projects. Getting user feedback ensures that the features being added (and the specs as defined by the tests) are actually easy to use.

3. Excuse for lack of Documentation

TDD is very helpful  in understanding code and figuring out what should be going on. But it can never replace quality documentation. Unit tests are just one aspect of a well documented project. Well maintained UML Diagrams, inline class and method descriptions, as well as architecture guidelines are needed to easily figure out the most important use cases, the key core, and the high level architecture.

4. Letting Architecture Decay

Often codebases that rely heavily on TDD are slower to refactor when the need arises. It becomes more difficult to modify the architecture when you need to update your test cases. A young project with swiftly changing use cases will need the flexibility to rapidly switch architecture whenever necessary. It should not be put off based on the number of unit tests that will need to be updated.

5. A roadblock to ‘innovation’

Sometimes doing new things means that you don’t know what the result will look like, how well your algorithms will work, or whether the caching will be fast enough. In such cases it is hard to have all the specifications (tests) written upfront. Often tests have to be written well after the experimental phase of a new component is completed. Waiting to create tests until you have a clearer picture of an innovative component will save many headaches and test rewrites.

Others?

The above is just a list of some of the more common forms of problems caused by applying test driven development that I have encountered. Have you found any others? Have you figured out a way to make sure teams stay on track?

photo credit: flickr

 

I am writing new articles once every 2-3 months. Interested in getting notified? Sign up here.