An unscripted unit test tool


Yesterday I ran in to a bit of a debugger bashing with a couple of people disowning the debugger with statements like “I noticed as soon as my students got access to a debugger [rather than just ‘print’ statements], their design very quickly deteriorated” and “I often feel that it’s much faster to reason around potential causes for bugs than to search for them in a debugger”. Now, these statements are undoubtedly true, but I am a huge fan of the debugger and will use it extensively in just about any programming task that I do. Admittedly, I do no longer do programing as my main profession, but I still code small tool in various languages, so this dialog got me thinking on why I find it useful.

I tried to think about how I use the debugger when I’m coding and then in struck me; I use it as a tool for unscripted unit testing. I have the feeling that many people, when they think of unit testing, they think of small pieces of code that check some other code. I also do this and find if very useful, especially as a way to constantly refactor and improve my design. However, these small snippets of code can be seen as test script and although there is value in these test scripts, there is much more to testing. Also, the code snippets do not really test the code, just check it – I want to test it.

What I do when I code is after every so few lines of new code, I have a micro test-session where I explore the new code where I can really test it beyond the (simple) checks of my scripted unit tests. For me, this adds invaluable information about the code that I have just implemented, that I feel I could not get otherwise.

As with most tools, their value depend on how you use them and with the debugger, it might not be a good tool for software design or for investigating bugs, but as a tool for unscripted unit testing, I find it to be great.