What I’m saying is that this doesn’t strike me as a danger of TDD so much as a danger of not thinking.

Weeeell. Maybe. I think the difference testing code and testing specs is quite a subtle one - not one I would characterise as people not thinking.

1. I have a requirement. I write a test to illustrate part of that requirement. I then write the minimal code I need to write to make that test pass - refactoring as I go.
2. I have a requirement. I need to write some code to meet that requirement. I write a test that will fail without that code. I write the code.

(1) is TDD. (2) is just writing the the test before your code.

I've encountered a several people who say they're doing TDD when they're doing (2). It was certainly a stage I went through when I started down the TDD road.

It's an easy trap to fall into. Well, more of a local maxima than a trap. (2) is still good - much better than not writing tests, or writing tests post-code. But it's not TDD because the design is not being driven by the tests, so you miss out on all the benefits that gives you.

I agree this is not a danger of TDD. It's a danger of doing something that looks like TDD but isn't. Describing it as a danger of TDD is counter productive. People tend to read it as "I should not do FOO because BAR will happen" rather than "If BAR happens than I'm not doing FOO correctly".

However I do find these consequences interesting. The places where people are doing wrong when they think they're doing right are useful areas to explore for at least two reasons.

Firstly they highlight areas where people learning a practice can go wrong.

One of the questions I regularly ask when I'm introducing people to TDD is "Why did you write that test?". If the answer is something like "Because the store can receive multiple orders at the same time" then things are probably going okay. If the answer is "Because I need to add an array to keep both orders" then some gentle nudging might be in order.

Secondly they highlight areas where we might need additional mechanisms to catch the errors.

For example the problem of the programmer tests and the spec getting radically out of sync doesn't tend to happen in groups doing Extreme Programming because they have additional practices (customer tests, not restricting TDD to just unit tests, short iterations, etc.) that catch these problems early or prevent them happening in the first place.