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.
This 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."
particularly 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.
...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.
I 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.
> But how many test suite have you seen which are less helpful?
I got ya. I have worked on software with a buggered mix of mocked and integration tests that fails about one time in four. But since the bug was in some asynchronous code and would appear in random tests, with random errors (even on thoroughly mocked tests), we can't easily smash it. It's one of those heisenbugs where enabling logging would cause all the tests to pass consistently.
And to put icing this cake, the software worked - this bug wouldn't appear in the production deploy.
So, yeah. The test suite was less than helpful. It certainly couldn't prove any qualities about the software we were writing.