TDD Harms Architecture

TDD Harms Architecture

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.