I suppose, if one gets much ego-boo from showing off one’s debugging chops, a test-first or test-driven style might be a problem – because you don’t have much debugging to do.
(Tip o’ the hat to Liz Keough.)
Ever since Kent Beck first came out with his book “Test Driven Development: By Example” in 2003, I’ve been using his brilliantly simple technique to create working software:
Sometimes, I find myself unable to figure out a way to get through step 1. Maybe I can’t think of how to test the new functionality. More likely, I can’t think of a way to test the new functionality given the toolset I have available to me. (Not all programming languages come with good automated testing support, after all.)
I don’t let the lack of tool support keep me from adding functionality to whatever it is I’m coding. On the other hand, any code I write that’s not covered by automated tests invariably has more bugs escape my desk than the code I write that is covered by automated tests.
And that, in a nutshell, is why I code test-first.