The importance of unit tests

Today I made a small change in a class in the application I'm working on. Being a diligent monkey, before adding the new feature I wrote a small dedicated test. The test failed, I added the feature, the test passed, I cleaned up a little bit (not too much, having just added three SLOCs) and finally committed the class in our SCM before hopping on to the next feature.

After a while our Continuous Integration Server pitilessly sent me a mail in which it informed me that the build was broken. No, better yet, that I broke the build, causing not one but 17 tests to fail. O shame and amazement, how was it possible? I had even written a test...

Despite all apparences, this is very good news. Why, you ask, grasshopper? Let me ask you a question: when do you want to know you have a problem? talking about software development, as soon as possible. Those 17 failures have saved me from delivering buggy code that would upset the user and set the stage for some annoying debugging sessions.

This has only been possible because of the test harness: all the time we spent writing tests has, once more, paid off well. So, without forgetting to add a test for the previously unchecked condition, I fixed the code in double-quick time.

I wish all managers understood this: writing tests is not a cost, but a tremendously effective cost saving tool.

Target 500 reached and passed

As our CI server is approaching to the 300th build of the project I'm working on, I am proud and happy to announce that we have reached and passed the 500th test, as we now have 528. Maybe #500 was mine, maybe it was lm's... or maybe it belonged to someone else. What really matters is that now it belongs to everyone, and it adds up to the status of good health of the codebase.


The number of tests has constantly grown, and the bar is almost always green - even if I should say that, using Hudson, the ball is blue (or the bar is blue, if you delve into details). I'll never get tired of saying it, CI server are really a wonderful tool - obviously if you provide tests for what you build, but that goes without saying.... or does it?

Build #100

I have been a bit inactive on the blog in these days. This is why:Nice birthday present, insn't it?

No bump, no set, a spike

Yesterday we ended our second iteration on a brand new project, in which we are trying new technologies and some adjustments to our process. We choose a story which touches almost every layer of the application and made an architectural spike: more a proof of facts than a real application, as we oversimplified domain objects and processes, but it gave us some good insights.

Unit testing is great (and TDD even more), as it forces you to carefully think of the design of your collaborations. And I'm not talking about "Design", rather I'm focusing on simple objects with clear behaviours. After all, tests are the first clients of the objects that make up our applications, and if they're difficult to test it means that they are also difficult to use. As we're totally on a green field, we agreed to not to write any line of code without having a corresponding test first, and it gave us great results. That was very difficult in some legacy applications, due to a very long list of factors (e.g. the persistence mechanism is embedded in every domain object and you can't test anything if you don't have the whole system up and running. Please don't ask, it's already frustrating enough).

Continuous integration is a huge boost for quality, much more than simple unit testing, as it has a broader impact and checks for defects against the work of all the team. Besides, no one wants to break a build and let everybody else know, so you also get improved committments for free. We also configured the PMD plugin for Hudson to report hints for cleaning and refactoring.

Paper cards for story and tasks helped us to easily visualize how the iteration proceeded; keeping the tasks small increased the effect of cards moving from the "open" column to the "closed" one.

We also tried a very simplified variation of CRC cards, based on outdated visiting cards; maybe I'll post something about it, sooner or later.

We tried some technologies that were unknown to some members of the team, but we faced the risk and resolved the problem pairing the untrained members with (more or less) expert ones, who enriched the sessions with many explanations about the basic concepts.

Due to several external incidents which required the help of the team, we didn't have enough time to deliver everything we had planned, but, as we previously agreed on which tasks were droppable, there were no problems in reaching the iteration goals nevertheless.

All the team is now looking forward to the next iteration, which is a very positive achievement.

My baby Hudson is growing...

We are starting a brand new project (er... that would actually be a third rework, as it is an inherited legacy application which had been already reworked twice from a previous group of developers) which will be the first real one on which we shall use a CI server; the selected product is Hudson, which I've tried a short time ago.

Installing on a separate server was a little more trickier than on my machine, on which I already had a fully working and customized version of NetBeans. Anyway, I was able to install and configure a bunch of features, e.g. access control and e-mail notification. I have also installed some plugins, like the Task Scanner plugin and the Violations plugin, configured to use PMD after quite a struggle - at least now I know something more about how NetBeans stores informations about libraries and build variables. More on this, including my temporary selection of rules, will follow.


Don't worry about the many broken builds, the project actually consists of a single class with a test class, and all the errors helped me experimenting :-)

Hudson and Cobertura

I've finally managed to setup a Continuous Integration (CI) server (you waterfall people can find a wonderful explanation on CI here). My choice fell on Hudson, a simple but effective server wich can be expanded with a bunch of plugins, which you can also write by yourself. But, being programmers lazy guys, and not wanting to be an exception, I scanned the published plugin list and picked the Cobertura Plugin. After some head-banging on the wall (yes, programmers never read the instructions) I tweaked the right files and had all the system running and configured for a pilot project: now the system periodically updates the local repository, builds the project, injects the Cobertura code ("instruments the classes bytecode" would probably be a better description), runs all the tests and displays the report on test results and code coverage. And if someone has broken the build it sends her a warning mail. Thanks again to Fabrizio for the inspiration.

The next plugin I'm going to try is the Google Calendar Plugin (my most informed friends know why).