The ten pros and cons of unit testing

Aug 04 2009 Tags: , , ,

Blogging burns a lot of caffeine. If you enjoy my posts, you should buy me a cup of tea.

Buy tea
Last Act of the Fallen
Image by ecstaticist via Flickr

Some of you may remember my writing about how unit testing is anti-productive and those of you I have to disapoint, I still dont’ think it’s the best productivity tool out there.

BUT!

The past few days I had another go at unit testing while developing a “server” for gathering statistics on how people use Twitulater. This was mostly in preparation for making a “server” for syncing Twitulater users, more on that some other day, it was mostly a learning exercise.

What I learned was that:

  1. Unit testing is no guarantee for quality (con)
  2. Unit testing can be really cumbersome to use and more time can be spent finding a test than solving the problem. Like for example: How do you test an app that reads from sys.stdin? (con)
  3. Unit testing only helps with bugs you’ve anticipated or found

    ---
    Need a freelance developer? Email me!

    You should follow me on twitter
     Subscribe to RSS

4 responses so far

  • Foom

    I think you meant 4 cons and _6_ pros.

  • Paul Loveridge

    You missed one out :

    Unit testing allows teams to have more confidence that their work isn’t breaking someone elses work by accident. (pro)

  • http:/giorgiosironi.blogspot.com Giorgio Sironi

    I’m glad that you see more pros than cons.
    2 imho is not a con since code that is hard to test cannot exist, since you must write the test first and then the code under test. That leads to more decoupled code, in this case decoupled from the assumption that the input should came form sys.stdin.

  • http://tobyho.com Toby Ho

    Nice write up. Like your blog. IMHO, Integration testing is just hard to automate, and you have to find the right cost vs benefit to do it. However, the TDD camp – in general – are not so big on integration testing, they are mostly concerned about unit testing THEIR code, and usually use mocks to mock away the integration points. This makes tests easier to write and run faster, but unit tests are not as useful as integration tests. Their thing though, is that doing TDD style coding forces you to write well-decoupled code, and the testing is only a part of it – in other words, testing isn’t their only goal. But, I think after you get to a certain point of experience, you can probably make the right decision as to what to decouple and what not to.

    I don’t write tests for UIs anymore. I change the design all the time, so what’s the point? Besides, designing UIs is a visual and interactive process, and there’s just no way to automatically test whether a UI looks nice or is easy to use.

« Why I hate working from home How MAFIAA killed itself and why... »