I follow a practice I like to call "test minded development". I write tests at the earliest point I feel appropriate - but rarely before I actually write code.

I follow a practice I like to call "test minded development". I write tests at the earliest point I feel appropriate - but rarely before I actually write code. I tend to work on greenfield projects, so writing tests before I write code rarely makes sense. IMO, TDD only makes sense if you already know what you're going to write. This makes a lot of sense if you're working on a brownfield project or following predictable patterns (for example, adding a method to a Rails controller). If I'm doing actual new development, as I code, I tend to write a lot of pending tests describing the situations I need to test. However, I don't typically implement those tests until after. One of the biggest factors for me is so much of my code deals with handling some degree of unknown - what the client will need, exact how an API works, how errors/invalidations are handled, unexpected refactoring, etc. In this case, it doesn't make sense to create tests before I write the underlying code. Most tests will have mocks/stubs/simulations that make assumptions about how the code works. At that point, a pre-written test is no better than code, since it's just as likely to contain errors. I much rather do real-time debugging/interacting while developing then capture the exact interactions of outside systems.