October 4, 2005
Most folks are now familiar with Test First or Test Driven Development. Write a failing test, make it pass. Having software based tests that exercise specific units of functionality is one of the foundation stones of agile development in general and XP in particular. But to be honest (and I suspect I’m not alone) I don’t really do stuff in this order too much. Once I’m happy with the architectural aspects of whatever it is I’m working on, I often start by sketching out some interfaces and empty classes, putting together a rough framework. This is a cheap exercise with Eclipse, as is refactoring if I don’t quite get it right first time. At the same time I start to outline some tests, and I jump back and forth between code and test. Often what I do is something I’ve come to call Comment First Development. I create a class, it could be the functional one or its unit test, and then I start writing comments. These comments are my way of working out the details, and they will (with some minor rework) become the comments for the code I have written. I suppose this is kind of like writing your psuedocode in days of yore – before stamping out the punch cards 🙂 – but looser and quicker and a lot more flexible I reckon. I find CFD works even better when it comes to changing code I haven’t written. I write comments where I think stuff should go, and I tag them with some sort of short string code that’ll be easy to find (e.g. DWZH). When I think I’ve outlined all the bits I’m going to need, I can do a search for my code and step forwards and back through my comments in the Eclipse search results view, checking what I’ve said. Then the coding is easy, and hey it all works first time (yeah right). DWZH = David woz here.