An observation about test-first development.
Once you get used to it, it's pretty easy to stay diciplined and not write a lot of code without having written a test first.
But I have found that once I have a somewhat large body of code already in place (my Worm game) and then go about implementing a new feature, starting with a test isn't always what feels like the most natural thing to do.
Often, I think about the feature, how to solve it. Then I think about the existing code, how to merge the new feature into what's already there. It's often a new line of code in an existing method, maybe a call to a new method, and I start to write that call. The obvious influence on the new method signature isn't an abstract test case; it's the existing code! The context makes it obvious what I want from it, and what parameters I need to pass.
Then I create the method signature and write the POD API and... then I have a tendency to start implementing it! The first method call I wrote feels like a test. Yet it isn't and it doesn't fail.
Maybe it's not important, maybe it's what works for me. Maybe this shouldn't have to be a problem, except I've found that there there is a higher risk I'll end up with no tests at all for the new method if I don't write them early on.
Is it just me?