If people don't have the same positive relationship with tests that you do, I could easily see "writing tests" generate enough negative sentiment to seriously degrade a person's capacity engage the near whimsical part of the brain that allows one to think laterally at non-trivial 'distance' from the obvious problem. It could easily be as simple as writing tools is more inspiring / engaging to the OP than writing tests.
I'll chime in here because it looks like you've had a terrible time with someone who's a [insert word of choice].
TDD "evangelism" is often toxic and abusive. The actual practice of a functioning TEAM (not just the devs) who know what it is and how it works, changes things fundamentally for the better.
Spikes are used to do the "whimsical" how the F do we do Y, parts. XP devs don't TDD those and the code is usually tossed out (with the good bits used to help build the production code.)
Similarly TDD isn't a religion, and only an fool would apply it like one. The good parts are, you get a test suite, you get developer examples of how to use a unit, you get an extra step to think about naming, so you're _slightly_ less likely to be saddled with a poorly thought out API / naming scheme.
It's broadly useful, helps teams integrate code, much faster.
Everyone needs to be playing the game, though, and they need to know the rules.
C2 wiki is about the best place to find organic conversations about XP and TDD (archived though, so no sanctimonious claptrap from the likes of me), and the wide internet is a great place to get polarized.
I'm sorry you got a bad taste, and it may have put you off, but a functioning TDD team is about the sanest, quickest, dev team you'll have the pleasure of working with. While, as you've found, an oppressive diktat to DO TDD PROPERLY when the team isn't really doing that, is hellish.
