I wouldn't know what resource to point without having a lot more context. And even if I had, I don't feel qualified to properly give you a diagnostic. All I ca

I wouldn't know what resource to point without having a lot more context. And even if I had, I don't feel qualified to properly give you a diagnostic. All I can give is my anecdotal evidence. Most of our development teams apply TDD most of the time. We're working on a mature (5y) enough codebase to have a stable foundation. We do lots of integration testing and our testing is not without issues (it's slow, some of it is flaky, lots of test fixtures that are a pain to manage) but those issues do not come from TDD and are being dealt with piecemeal. The only downside of TDD I've personally witnessed in practice is tendency to write superfluous tests. They either don't test anything useful (e.g. things already guaranteed by types) or leak implementation details. But we encourage developers to improve those tests and the engineering team is overwhelmingly positive that TDD has been a net win for productivity. We try to deploy as much pair-programming as we can and the TDD methodology is specially improved by this. It helps dealing with loose ends from the task description or the technical kick-off and double-checking if the task acceptance criterion makes sense. If one developer of the pair has to take off halfway through, the most important bit is already agreed upon and the code review is much easier later on. Or if the pair-programming starts halfway through, the arriving developer can read the tests to catch up and help make the other tests pass.