I rarely use TDD for prototyping or even the first version of a project. I tend to only write tests on my second pass through a chunk of code (generally when I'm refactoring it).
Works for me perfectly well, and I don't give a damn what the TDD True Believers think.
I think even the true TDD "purists" would say you're doing it exactly right...
Robert Martin usually says "You are not allowed to write any production code unless it is to make a failing unit test pass."
When I'm writing code to solve a problem I've never solved before, I don't write tests. But then I scrap it and write tests first, implementing code to pass the tests. It may sound wasteful, but I have enough experience behind me to know that those tests come in mighty handy about six months later when I want to add in some crazy new feature I didn't think of before.
Heck, I even do that with new features - I'll branch, write it, see if it works, then branch again off the master and implement it again with tests. It's not much extra work really, and I often do catch little mistakes I made in the "prototype" version.
But it's taken me a long time to get used to TDD, and I feel like I'm still learning. I occasionally find myself over-testing. Like anything else, it's a discipline, but I find it so worth it.
Yes, and I take that to mean anything that's non-trivial or experimental. I've heard him speak on the idea of experimentation before, and that's what led me to the methodology I use today.
Works for me perfectly well, and I don't give a damn what the TDD True Believers think.