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?
I solve that by adding a suite of customer tests that make as few assumptions about the internals of the code as possible and test as much of the code in one swoop as possible. Then, when the new customer test or tests fail, I start writing developer tests.
