Friday 29 October 2010

Slow work and intro to TDD

I have been very busy lately, so I have no spectacular news to report. Still no foil device to install in the beam line, so we're slowly preparing the rest of the setup and doing analysis for other experiments. Exactly what my french companion in physics and I came down to CERN for. Ah well, it could be worse, we could have been Ph.D.s at LHC a few years ago.

I still haven't ordered that strat. I haven't even played much guitar at all lately in fact. I will order the guitar in two weeks or so and then I will have to make time for it.

Just before summer I believe, a friend of mine working at Erlang Solutions in London (his blag) tried to convince me to embrace TDD, Test Driven Development. I had heard/read about this before, esp. from extreme programming and Netbeans, but I never invested time in "getting it". After all, most people applied this in functional languages or thereabouts so I never did care much. Two things have changed: I learnt to like C++ and I stopped being a C zealot. I still don't like the long build times, but computers are getting pretty fast these days so who cares. With C++ in a new light and a new set of less cynical eyes, I started looking into safe source code. That's one of the selling points with C++ over C, after all. I started thinking about my friend, because he develops high profile and highly reliable software that _must_ work (the amount of tolerance on software quality at release is terrifying imho) and I started asking questions and looking things up. It took a few tries until I found introductory articles which gave me the right idea. TDD is basically "write tests, then write code". Because TDD is very different to how software is otherwise developed (i.e. "I have to write all this code to reach this goal"), authors tend to complicate their articles immensely. To be fair, this is a recurring problem in anything remotely academic. Anyway, after "getting it", I developed my own rather capable super minimalistic testing framework which consists of one header file and one source file which have everything I need for the moment. Minimal code, minimal problems, maximum understanding and maximum control. I plan to use this to develop a few graphics demos to get in the groove, and then I shall aim towards bigger, better, stronger and faster endeavours. Not really a Daft Punk fan, good stuff nonetheless.

Small side note on how TDD will help me immensely: I always, always, go back and read through old code during development. For example, I have very often been victim to the effect of rotting code (leave some code "untouched" for a good while and bugs somehow creep into your code). I am tired of this paranoia, continuous testing would help me feel much more secure. I am fully aware of that TDD does not catch every potential bug, nothing except possibly a Spider Mastermind can do that. However, TDD implements a granularity of testing which is practically impossible to achieve if you put testing code when your SLOC shoots to hundreds of thousands.

So, the next blog post will probably be a bit about some stupid graphics demo that I wrote using TDD. Do not hold anybody's breath. (EDIT(2011-10-25): So, no, no graphics demo :p )