I don't find much need to have done the thing before.
Before I write a line of code, test or no, I usually have some idea of what the code should do. Then I run the code to see if it does what I want. So if I'm not doing TDD, I'm still doing "manual test test first"; the test is just in my head.
TDD is just saying, "Let's start by automating a bit of that test and make the test fails correctly. Then we write production code until the test passes. Once it goes green, we look at what we've got, see how we like it, and maybe refactor a bit before writing the next test."
If I'm totally off the map and flailing around, yeah, I won't write tests first. I'll hack at something until I have a clue. And then I'll throw that code away and write my first test. Which is something I should do regardless of whether I'm doing TDD, as scratch code like that is too messy to keep. Easier to dump it and start fresh.
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.
Yeah, almost everything good in tech attracts people who push a good thing too far. If not for working with some reasonable advocates, the FP zealots would have seriously put me off the techniques entirely.
Before I write a line of code, test or no, I usually have some idea of what the code should do. Then I run the code to see if it does what I want. So if I'm not doing TDD, I'm still doing "manual test test first"; the test is just in my head.
TDD is just saying, "Let's start by automating a bit of that test and make the test fails correctly. Then we write production code until the test passes. Once it goes green, we look at what we've got, see how we like it, and maybe refactor a bit before writing the next test."
If I'm totally off the map and flailing around, yeah, I won't write tests first. I'll hack at something until I have a clue. And then I'll throw that code away and write my first test. Which is something I should do regardless of whether I'm doing TDD, as scratch code like that is too messy to keep. Easier to dump it and start fresh.