All testing is not valuable. There. I said it.

If you take a look at the source of Blaag, you might notice a certain lack of tests. No unit test, no tests at all in fact. Does this mean I do not believe in unit tests, TDD and testing in general? No! If you take a look at hgapi, for example, I wrote almost all code using TDD since that was the only way to know I got it right.

When starting on Blaag (which did at the time not have a name), I began by creating testblaag.py, writing import unittest – and then I froze. I had no idea what a test for Blaag would look like. Everything Blaag does, is glue code. It fetches data, feeds it to docutils, collects some additional data from Mercurial, creates documents using string.Template and a RSS feed using PyRSS2Gen.

There are some utility functions (implemented as functions or not) that I could have created unit tests for, but what information would I draw from writing a test for sum([int(i) for i in hgdate_string.split()])? I write this code for me, and for me this code is obvious. So how do I know it works? I test it. Manually, since generating the entire html source is the only way for me to know that Blaag works as I intend it to work.

Whereas when writing hgapi, I wrote a tool for others to use and adapt, and a tool that I could not easily look at and see if the result was correct, Blaag is easy to verify: I look at the rendered site, in my browser. If it does not look OK, I have a bug. If it works, I have NO bugs. I might have potential bugs, like the fact that the -f option is currently required when updating, but if the code generates the result I want, consistently, and in reasonable time, Blaag performs perfectly.

Any test would simply be more code that did not add information or value – and there is a name for that kind of code: bloat. And while in the case of Blaag this is easy to see, I believe that more care should be taken generally when writing tests, just as when writing functionality – the question you should always ask yourself when producing code is simply: what value does this code add? If you cannot answer that question, you probably should not write the code, whether it’s a test or not.

Because code unwritten never breaks.