This is the material piece of information which lead to the fix. Your TDD simply made it faster to locate the offending line.
Seems like a really poor justification for TDD imo.
The stack trace tells you where the error is occurring, your intuition leads you to the relevant caller function that you should test, stack trace or logs should lead you to the offending parameters (i.e. the weird name).
With these three pieces of information you can write a failing test and implement a patch.
I don't consider this approach to be "TDD", just "software development with good test coverage".
> The dev manager had everyone take a day of TDD training after that, but nobody really understood
That is exactly the problem with TDD or any other methodology that is hard to get right. Methodology will either push to a pit of success, or a pit of despair. If it's hard to get right, pit of despair it is.
Force 100 people to do TDD. 95 of them will be harmed, 5 will succeed. Same if you do waterfall. Same if you do Visual Basic. Same if you don't do code reviews.
TDD is indistinguishable from any objectively malicious practice. Somehow the fact that few folks were able survive TDD, is twisted to present TDD as some kind of holy grail.
A story: I used to work with some devs, most of them would finish coding something in 2 weeks and then spend a week debugging it. I'd take 4 weeks to TDD something. My boss was frustrated at my speed until one day a production system which I'd written, stopped working. Several million dollars was stuck in limbo, the backend team responsible for the paperwork unable to do anything. We had a new dev and the bandwagon was "TDD is crap!" was fully rolling that morning. I asked the backend processing person what had changed? The said we had a new client, they had a weird name. Looked into the client log, sure enough. Added a test with the client's name, and ran the tests. It spat out "1 failing test in module X at line Y because 'this'". Modified the code to handle that test, re-ran the tests, 100% pass. Emailed the results output to the team for a manual upload, processing done, committed and pushed to the production branch. The server would update after business hours. Diagnosed and fixed in 5 minutes. I turned to my colleague who I knew was still stepping through his code for 2 days and said (within earshot of the new dev) "How's that bug you've been hunting? Still not found it? This is the power of TDD. I might be slow at the start, but I fix bugs quickly". The dev manager had everyone take a day of TDD training after that, but nobody really understood. The trainer said my approach to TDD is too strict, with my team doing 110 test runs against the next team of 63 test runs. Our solution had only a few lines of code verses the paragraphs of the others though.