I do not ascribe to TDD as a good design philosophy, so I almost never write tests first. I'm also a functional programmer. So for business logic, I generally write exhaustive tests... not just hitting every happy path, but also testing for every possible error condition. Since I'm testing pure functions I don't have to test for the universe of IO errors -- just business level errors -- so it's not as daunting as it sounds. I haven't yet gotten into the realm of property-based testing, although I hear it is nice there.
While TDD can help you think about how you are going to design things, it is not a design philosophy in of itself. The thing I love about TDD, is that it makes testing part fun for me, and replaces the time I would have used to see things running in the debugger. People often think that because you do TDD you don't need to think first about how you are going to design or layout your code. This is wrong, you still need to do some kind of high level design to know where things are going to go, but not get too stuck with your initial thoughts or plans if you see the need to make changes as you go. Often I find testing the most difficult part of coding, and forcing you to get this out of the way first is one of the reasons I love TDD.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.