3 ms·
> I asked one of the proponents how they handle the fact that tests can easily increase the complexity of a system by adding more code. Adding more code != mor
by hacker_9 9y ago
> I asked one of the proponents how they handle the fact that tests can easily increase the complexity of a system by adding more code.
Adding more code != more complexity. Complexity comes from high coupling between code, that doesn't separate concerns, which make it difficult to untangle, aka. spaghetti. Unit tests are mean to be simple, and anything they test will be no more complicated that how the system will actually be used. In this way they clarify the code, by encoding the intent, available for all to see for years to come.
> I've gone back to liking larger, more monolithic functions as often I don't want to create a bunch of generic functions for hypothetical use for other projects, I just want some code that fits my needs to a T.
This isn't what TDD causes, it just makes you break down things into small testable units. It doesn't make you create super generic wrappers, which I also agree are useless because of their un-readability.
- gilbetron 9y agoAgain, this is the argument made to me over 10 years ago, and again, they are wrong. While it is possible to add more code and not get more complexity, it is very difficult. Generally speaking, adding code adds complexity. Full stop. Excellently executed TDD will reduce overall complexity, but I almost never see that level. Rather, TDD's ability to catch bugs is mostly enough to reduce bugs (and other benefits) overall. But the costs are high.
- hacker_9 9y agoTests make clear the intent of the code, how else can you get that exactly? And the next time you have to fix a broken unit test, think of how much time it has saved you by constantly running autonomously as part of your build process.