Test-Driven Development is a powerful way for developers to approach both the design and implementation of systems.  However, organizations that embrace TDD typically run into difficulties over time, once the test suites become large.

Here are two challenges they face.

• New requirements, expressed as new tests, drive changes to the system that make the new tests pass, but at the same time cause many of the older tests to fail. The test suite must be constantly maintained, and this represents an increasing burden on the development team.
• Tests become disconnected from the system. This is easy to miss, because the default behavior of an automated test is to pass; if the tests are not actually exercising the code any longer, then the tests will still pass even though the system is behaving incorrectly or incompletely.

These problems are so commonplace that many have concluded that TDD, while a good way to start a new project, is not sustainable over the long term. As the suite of tests grows it eventually represents such a maintenance and validation burden that the process must be abandoned.

This does not have to be the case and should not be allowed to happen. When test suites become unsustainable it is because developers have not been properly trained in how to create them. This involves:

• What tests should be written
• How these tests should be structured
• What tests should not be written
• The process by which changes are made to the system
• How legacy code is integrated into the process