Yesterday I had a very interesting discussion with Peter about test driven development. We came to talk about it because of a small project I started a few days ago. It's a simple chat server that will perhaps replace our existing one. I've started similar projects before but failed miserably; one recent reason has been me being too focused on getting everything tested using a unit testing framework.
I know Peter has written about this before, but I think it's worth repeating: it's almost impossible to write untested code. You might not have automated tests and you might not use a testing framework, but you do test the code.
Yesterday I also completed a simple spike of the new chat server. My intention was to come up with a very simple program to test (there's that word again) a few ideas I had, and to straighten out a few question marks. Looking at my recent failures of completing similar projects I decided to skip the testing framework and the unit tests. And it worked. I've met my goals with this spike. Every single one of them.
So, there's no such thing as untested code. But, depending on what kind of testing you do you get feedback earlier or later. The earlier you get the feedback the better, and getting feedback early is the essence of UnitTesting.
But you also have to consider the cost of setting up and executing the tests. In my chat server spike there's a lot of BSD sockets code, and I find that code hard to UnitTest. An alternative that I'm now considering is writing a few small server and client programs based on the code in the spike. These small programs will be designed in a way such that they can be used easily from a shell script. This way test suites can be set up easily and hopefully even run automatically every time I make a change to the code and recompile!
I'll probably come back to this subject in the future so stay tuned!
