I recently had the paradigm shift that Test Driven Development isn't really about writing your tests first, it's about doing your development IN tests.
Instead of writing some code, running the code, repeat...you write some code, write tests that run the code, run the tests, repeat.
It's literally about the tests DRIVING the development.
@urusan It really doesn't work for me, but I respect it works for other people.
I get frustrated when I write a bunch of tests mid-development and discover the API is busted and I need to re-work it. Much easier for me to sketch out the API, then a bit of implementation (while I think ahead on how it'll be used), realize there are holes and rework it, *then* write the tests.
OTOH, maybe that just means I'm doing TDD in my head.
@mtomczak Another note is that you don't have to stick to the unit test paradigm strictly. It's okay to have integration test(s) to drive (early) development with rather than only using unit tests (though these integration tests will almost certainly be in your unit test framework, they're just relaxing the "unit" part).
It's also best to write your tests to only use the public API, which reduces the chances of changes, especially if your public API is already in use and should thus be passive.
@mtomczak If we're going to be honest, I'm kinda anti-unit test.
Someone pointed out to me that unit tests are really more of a design artifact than a testing artifact, and now I see full unit test coverage as a symptom of an over-designed system. It's great if you have every design detail planned out in advance, but it stalls iteration.
Human-performed testing rarely resembles unit testing anyway, they're mostly end-to-end or integration tests, so why not automate those more realistic tests?
With statically-typed languages, because there's so much code on the tests to change when you change the interface, I tend to write the code first at least until I'm happy with the way in putting together pieces of the program, so that I know the interfaces are somewhat stable, and then I write the tests.
In the end though, it's quite rare I'll write the tests first unless I'm editing old code, even if I'm working with a dynamically-typed language.
@mtomczak Well, this case is where my paradigm shift helps a lot.
You don't have to write a lot of tests if your API is uncertain. You can just write a few key tests and use those to drive most of your development. Then it's a low cost to change your API and tests.
Even by just having those tests, you make it easy to write all the rest of them (and all the better if you write more tests as you go along).