4
Aug

The ten pros and cons of unit testing

   Posted by: Swizec   in Uncategorized

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
    Share and Enjoy:
    • Digg
    • Sphinn
    • del.icio.us
    • Facebook
    • Mixx
    • Google Bookmarks
    • LinkedIn
    • StumbleUpon
    • TwitThis
    • DZone

    Tags: , , ,

If you liked this post you should follow me on Twitter,
or see the music I like on last.fm,
or perhaps leave a comment, I like comments,
or go do your job because I know you're slacking,
or go write a blog of your own,
or tweet about something interesting,
or go out and have some fresh air,
or find a girlfriend,
or a boyfriend,
or a manbearpig,
or for fuck's sake stop reading this already,
no?
This entry was posted on Tuesday, August 4th, 2009 at 13:46 and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

4 comments so far

Foom
 1 

I think you meant 4 cons and _6_ pros.

August 4th, 2009 at 14:33
Paul Loveridge
 2 

You missed one out :

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

August 5th, 2009 at 10:40
Giorgio Sironi
 3 

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.

August 5th, 2009 at 16:08
Toby Ho
 4 

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.

August 6th, 2009 at 16:04
Back to top