3 ms·
TDD creates a large maintenance overhead. It more than doubles the code that has to be maintained for the lifetime of the software. This is by design since any
by zaphar 14y ago
TDD creates a large maintenance overhead. It more than doubles the code that has to be maintained for the lifetime of the software. This is by design since any modification to the codebase should start with a modification to the tests.
In reality though the tests often bitrot faster than the actual code does. The cost of the very large set of unittests generated by TDD only grows over time without contributing to the actual feature set of the software being developed. For this reason TDD does in fact introduce a large overhead with a potential savings in safety.
The controversy is introduced when people start to realize that the most bang for the buck comes from tests that exercise the public interfaces of the various parts of the software and that less and less benefit comes from the tests covering the internal parts of the software. Often the fine grained tests covering the internal details cause the internals to ossify and increase the cost of changes until finally they get abandoned.
TDD has it's place but taken too far it can do just as much harm as the lack of tests.
- dragonwriter 13y ago> The controversy is introduced when people start to realize that the most bang for the buck comes from tests that exercise the public interfaces of the various parts of the software and that less and less benefit comes from the tests covering the internal parts of the software. That's not TDD being controversial, that's details of how to apply TDD being controversial at most (and, really, its seems to be a "controversy" that amounts to saying "doing things that TDD doesn't ever call for is excessive", with no other side, which isn't a controversy, its a non-sequitur; if you are creating unit tests for internal details that aren't exposed, you are preventing refactoring, rather than enabling by testing all and only the required exposed behavior so that you can refactor the implementation of that behavior without changing tests, which is a central part of TDD. I suspect the problem with this is bad metrics used by some people who say they are doing TDD but have adopted measurements that imply standards that forget about the entire point of TDD, such as looking to ensure that every method is directly tested, which is clearly inappropriate.)