Tell us how you really feel :-D. I agree with you on some points, but I think TDD makes up for lack of uninterrupted concentration in a different way — you’re working in discrete units and you always know where you are. So when I was working in downtown Atlanta and I had a 3-hour round-trip commute, I could write a test before I left the office, make it pass on the train, get the next test written on the train, make it pass before my first meeting of the day, and so on. I never lost my place or had to reload all the context, because the test itself said clearly what was going on. As a bonus, that was documentation for later developers to truly understand the intention of the code.

The first place I go when I am having trouble understanding a poorly-documented library is its tests.

If you write big monolithic code, of course you have to spend hours loading up everything that you need to understand to work on it. Code written in intelligible chunks can be worked on differently, and TDD pretty much enforces that way of working.

I personally find little value in integration tests. If each piece does its job as designed and the system is well-designed, then problems will be obvious the first time you run the code, you fix it, and move on. In my world, requirements change so frequently that integration tests fall out of sync very easily, whereas tests of a small piece of code that might be moved are pretty durable.