[sloopy543]

Nope. I pretty much always find it to be counterproductive.

Most of programming happens in the exploration phase. That's the real problem solving. You're just trying things and seeing if some api gives you what you want or works as you might expect. You have no idea which functions to call or what classes to use, etc.

If you write the tests before you do the exploration, you're saying you know what you're going to find in that exploration.

Nobody knows the future. You can waste a crazy amount of time pretending you do.

[kragen]

> You're just trying things and seeing if some api gives you what you want or works as you might expect.

I don't do most of my programming this way, because mostly I'm writing new things, not gluing together existing APIs with a tiny amount of simple glue code. But when I do need to characterize existing APIs, I find that unit tests are a really helpful way to do it — especially in languages without REPLs, but even in languages that do have REPLs, because the tests allow me to change things (parameters, auth keys, versions of Somebody Else's Software) and verify that the beliefs I based my code on are still valid.

[sloopy543]

Yeah, I'm all for unit tests when they're needed. They just aren't the first thing I'll write

[Izkata]

You appear to be talking about unit tests in general, while GP was talking about test-driven-development (what the original question is about).

[kragen]

Good point, thanks.

[JustSomeNobody]

> Be prepared to throw one away. You will anyway.

Write a POC to learn then you can write tests first for production.

[AdrianB1]

You are right, but technically speaking you already did implementation for POC without having the tests. So the full answer is "do POC without tests first, continue implementation with tests first".

[EpicEng]

So, in other words... an "exploration phase" which is done prior to writing tests?