I feel exactly the same way. TDD helps me think about the requirements, because even if I’m building something as a prototype, I still have specific requirements in mind. Those will change as I get feedback for the prototype, but even a really, really simple test will help me be more secure in knowing my reworking of the prototype didn’t break some very fundamental needs of the system.
My guidance would be to not start with many tests when writing a prototype / initial development of something - just write one or two of the most basic things you’re confident you’ll need. As your finished product comes into focus, then you can add more tests.
I don’t literally write a test before every line of code, yet I still consider what I do to mostly be TDD.
Absolutely. For me it's an incremental, iterative process. I write a tiny bit of test. And then I make it pass, often in a way that's a little too simple. So then I'll go back and improve the test, which forces me to improve the code.
Writing too many tests feels like getting ahead of myself. It feels like a bet that I won't learn anything or think of anything new as I go. Which is a bet I don't like making, because it often becomes self-fulfilling.
My guidance would be to not start with many tests when writing a prototype / initial development of something - just write one or two of the most basic things you’re confident you’ll need. As your finished product comes into focus, then you can add more tests.
I don’t literally write a test before every line of code, yet I still consider what I do to mostly be TDD.