Unit testing revisited

In Programming, Timeline on January 4, 2010 at 9:57 PM

Every time I make a new release of Timeline I get a little nervous. Nervous that the program will not work or do something unexpected. One obvious activity that helps find bugs in the program is testing. Usually when I work on a new feature I try it out as I go and make sure it works. The problem is that I can’t say with confidence that other features still work: features I haven’t touched for this release or haven’t used in a long time.

One solution is to test all features before every release. That is a tedious job. Especially when you make releases often as we do (once a month). I have experimented a little with unit testing but find it quite difficult. We only use it in a few places to ensure correctness of a few functions. A podcast and an article pushed me intro trying unit testing again and also working in a test driven development fashion.

The podcast

In FLOSS Weekly 87: Extreme Prgramming With Kent Beck topics such as extreme programming (XP), test driven development (TDD), pair programming, and design patterns are discussed. It does a great job of demystifying these buzzwords and makes you understand the core ideas behind them.

In particular I like the fact that they go back and talk about a well designed program as one that has low coupling and high cohesion. Later they talk about how techniques such as TDD help achieve that.

The real eye-opener for me after listening to this show was that the purpose of writing unit tests is not only to test the correctness of a function: it is also designing your code in such a way that it can be tested. And if it can be tested it probably has low coupling and high cohesion which in turn makes it a well designed program. Kent mentions in the show that having the correctness of a function tested is just “a really nice side effect” of writing unit tests.

The article

Now I had a slightly more positive attitude towards unit testing and I wanted to try it out in practice by refactoring some code for Timeline. One thing that is typically difficult to test automatically is GUIs. In Timeline there is at least one GUI component that is quite large and contains much logic. I would be really happy if we can test it automatically somehow.

Browsing the net for answers I came across this excellent article: The Humble Dialog Box by Michael Feathers (found via How can I unit test a GUI?). It describes a totally different approach to designing GUIs that really fascinated me. You remove almost all logic from the GUI and instead put it into another object which can much more easily be tested.

The experiment

I decided to try the idea with a humble dialog box on the category editor in Timeline. It is a very simple dialog which makes it suitable for trying this approach.

For those of you interested, you can read the source code for this dialog before and after (source code for test).


Although the overall length of the code increased I think the separation between the GUI and the controller (the logic that was previously in the GUI) is slightly more readable. Most of the code fore the GUI is now extremely simple. So the increase in code size is not such a big issue I think. It also feels quite nice to be able to test the simple logic of this dialog.

I am still not convinced that unit testing is the answer to all problems regarding ensuring high quality. And maybe that is not the case either. After all it is just one means to get high quality code. I think doing code review is another good means to that same end. I might try this approach again on a more advanced dialog.

A side note

The Flawed Theory Behind Unit Testing (from Michael Feathers’ Blog) expands on the idea that unit testing is just a means to an end where the end is high quality code. From the post:

In the software industry, we’ve been chasing quality for years.  The interesting thing is there are a number of things that work.  Design by Contract works.  Test Driven Development works.  So do Clean Room, code inspections and the use of higher-level languages.

Go read the whole article if you are interested in knowing what it is that makes the above mentioned things work.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: