Mark Needham

Thoughts on Software Development

Writing unit tests can be fun

with 3 comments

I recently came across Pavel Brodzinski’s blog and while browsing through some of his most recent posts I came across one discussing when unit testing doesn’t work.

The majority of what Pavel says I’ve seen happen before on projects I’ve worked on but I disagree with his suggestion that writing unit tests is boring:

6. Writing unit tests is boring. That’s not amusing or challenging algorithmic problem. That’s not cool hacking trick which you can show off with in front of your geeky friends. That’s not a new technology which gets a lot of buzz. It’s boring. People don’t like boring things. People tend to skip them.

Small steps

While working on a little application to parse some log files last week I had to implement an algorithm to find the the closing tag of an xml element in a stream of text.

I had a bit of an idea of how to do that but coming up with little examples to drive out the algorithm helped me a lot as I find it very difficult to keep large problems in my head.

The key with following the small steps approach is to only writing one test at a time as that helps keep you focused on just that one use of this class which I find much easier than considering all the cases at the same time.

The feeling of progress all the time, however small, contributes to my enjoyment of using this approach.

Test first

I think a lot of the enjoyment comes from writing unit tests before writing code, TDD style.

The process of moving up and down the code as we discover different objects that should be created and different places where functionality should be written means that writing our tests/examples first is a much more enjoyable process than writing them afterwards.

The additional enjoyment in this process comes from the fact that we often discover scenarios of code use and problems that we probably wouldn’t have come across if we hadn’t driven our code that way.

Ping pong pairing

I think this is the most fun variation of pair programming that I’ve experienced, the basic idea being that one person writes a test, the other writes the code and then the next test before the first person writes the code for that test.

I like it to become a bit of a game whereby when it’s your turn to write the code you write just the minimal amount of code possible to make the test pass before driving out a proper implementation with the next test you write.

I think this makes the whole process much more light hearted than it can be otherwise.

In Summary

The underlying premise of what makes writing unit tests pretty much seems to be about driving our code through those unit tests and preferably while working with someone else.

Even if we choose not to unit test because we find it boring we’re still going to test the code whether or not we do it in an automated way!

Be Sociable, Share!

Written by Mark Needham

April 25th, 2009 at 7:51 pm

Posted in Testing

Tagged with ,

  • Pingback: DotNetShoutout()

  • Mark,

    Good response. I’ve written one here: http://blog.typemock.com/2009/04/unit-testing-is-boring.html
    The comments conversation is interesting. While I agree with what you write, you need to go down the path of unit testing for a while, trying and getting used to TDD or pair programming to understand that. But if you try to explain to people who haven’t tried anything of that – well to them it’s just about writing “additional” code. There’s no convincing argument that doesn’t involve their experience.

    At least, I haven’t found one.

    Gil

  • Whether the task is boring or not depends on person exercising it. E.g. exploratory testing is generally considered as boring too and I always enjoyed doing it since it gave me a freedom to move wherever I felt like and it brought some rivalry between tester and developer (which is fun).

    I think the same is with unit testing. It is generally considered as rather boring task. As far as you find fun writing them – good for you. It does mean your unit test are most likely great. On the other hand there are many developers out there who treat them as necessary evil and write them only because someone told them to do so. It’s no surprise it bores them.