3 ms·
Quite a few people are saying it doesn’t work. I have worked on TDD codebases where anytime you changed a function or tried to refactor something trivial it too
by pech0rin 5y ago
Quite a few people are saying it doesn’t work. I have worked on TDD codebases where anytime you changed a function or tried to refactor something trivial it took 3x the amount of time to fix the tests even though the code worked correctly as written. This is due to mocking or naming or expecting functions to never change. TDD proponents would say that is the “wrong” way to do it, which Im sure it is but that doesn’t stop it from happening and killing productivity.
- the_gipsy 5y ago3x is optimistic. Tests can "suffocate" a codebase to the point where no one dares to make any cross-cutting changes anymore, at all.
- convolvatron 5y agoparticularly since TDD organizations often maintain the constraint that the tests _should never change_ since they somehow embody the requirements. personally I'm not settled on an architecture until I'm part of the way through..I can't really understand how its all going to fit together until I'm in the process of building it.
- WolfOliver 5y agoThis matches with what the articles says: > "You change a little thing in your code and the only thing the tests suite tells you is that you will be busy the rest of the day fixing false positives."
- pydry 5y agoI have encountered this too, just as you and the author did. However, when I switched to integration testing behaviors rather than unit testing low level functions as the author suggests it went away. Traditional TDD proponents would say that what we're doing is definitely not orthodox TDD but IMHO it's the only way that actually works.
- usrusr 5y ago...and the 3x amount of time isn't even the biggest downside when that happens, that honor goes to how much the value of those tests erodes while they are being adopted.