Change is inevitable. Historically, most business applications have not dealt with change well. This is because most applications, despite the best intentions of the developer and architects, become brittle and fragile. Without the security of a unit and integration test suite, most applications devolve into the code equivalent of a Jenga tower. Before long, the application is so unstable that most developers are afraid to touch it, lest the whole thing come tumbling down.
These applications lacked automated unit and integration tests. Without a method to automatically regression-test an application that had a change made to it, no one could guarantee that the application would function properly after the change. Developing an application while practicing TDD provides a suite of these tests to ensure that as changes are made, the application itself remains stable.
The practice of TDD has another side effect that makes applications more flexible in the face of change. Developers who practice TDD, whether by design or as a side effect of writing code for testability, seem to follow the SOLID principles more than developers who do not practice TDD. Adhering to the SOLID principles results in software that is easier to maintain and extend. This is clearly a benefit in an environment where change is inevitable.
An application might need to change after being deployed to production for a number of reasons. Perhaps the company has adopted a new business ...