Yeah, this is interesting. Like anything it doesn't apply 100% of the time. The place where TDD works well is once you know what you're doing! Because otherwise, of course, you can end up testing things in the wrong place, as you realise things won't work and have to refactor them.
But in the case of bug fixing and adding simpler cases, where your tests are already there, writing a failing test first is an amazing habit to get into.
I think the counter argument to the whole 'but I'll have to keep rewriting my tests!' is, if you're not sure how to structure stuff, write the acceptance / integration test first - because you probably won't have to change that - and then start trying to work out how to satisfy that. Once you have something working, you can start TDDing with your unit tests until it is complete :)
While I wouldn't push anyone towards TDD, I would strongly push people away from integration test based development. The testing is not fine grained enough and test only a "walking skeleton", they are slower and they allow for terrible design. It's very easy to write integration tests which pass with a mess of interdependent code but very hard to do it with unit tests.
The major benefit of (Unit)TDD is that is pushed you to think about separation of concerns, ergo, good design.
Cool. I am trying to do as Uncle Bob says ;) I want integration tests to check that the code does as the end-user needs, regardless of its internal structure.
Agree that doing ONLY end-to-end / integration tests is a bad idea, as you say.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.