Testing basically breaks down into the following types (and you can flavor them however you want, but take this as a starting point):
- test-last testing to test the implementation you just wrote
- test-first testing to test the implementation you're gonna write
- test-driven design, where the tests reflect the specification and are applied to the implementation
So, with these on hand, here's my litmus test for TDD:
Do I know what I'm building and why?
You can't meaningfully do test-driven design if you don't know the what and the why. TDD tests need to encode "the business cares about this", and IME, the questions you are asking often arise when somebody doesn't really yet know what they're building. You're figuring it out. And that is okay, too!
I'm not a TDD devotee (in that I would love to write code in a TDD fashion much more than I actually do, but I think it's probably the right answer for most situations where the unknowns have been solved or pushed out) and I think that you're describing a very common situation where writing tests while you're writing code, or maybe even after--though this is often fraught--is totally fine. I regularly build systems by writing tests to exercise bits and pieces of them in lieu of opening a REPL or running it through a command line; the Test Cops aren't gonna come get you if this works better during your exploratory phase. (It does mean your exploratory phase has some useful artifacts when it's done, though.)
Put another way: if I have a spec, I can do TDD. If I don't, I can't, and I don't lose sleep over it.