The idea that TDD damages design and architecture is not new. DHH suggested as much several years ago with his notion of Test Induced Design Damage; in which he compares the design he prefers to a design created by Jim Weirich that is “testable”. The argument, boils down to separation and indirection. DHH’s concept of good design minimizes these attributes, whereas Weirich’s maximizes them.
[…]
A related argument is: The more tests you have, the harder it is to change the production code; because so many tests can break and require repair. Thus, tests make the production code rigid.
[…]
Think of it! If the structure of the tests follows the structure of the production code, then the tests are inextricably coupled to the production code – and they follow the sinister red picture on the left!
[…]
As the tests get more specific, the production code gets more generic.
[…]
Indeed, this is why TDD works. This is why designs can emerge from TDD. This is why algorithms can be derived by TDD. These things happen as a direct result of programmers pushing the tests and production code in opposite directions.
[…]
Is is only programmers, not TDD, that can do harm to designs and architectures.
