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 (con)
  4. Unit testing can quickly lull you into a false sense of perfection (con)
  5. Unit testing is a life-saver when you’re refactoring (pro)
  6. Unit testing is extremely gratifying – nothing better than finally seeing all those tests pass after a long night for a sense of achievemt (pro)
  7. Unit testing feels easy to use after the tests are written (pro)
  8. Unit testing provides repetitive and verifiable measurments – the scientific method(pro)
  9. Unit testing is great for verifying behaviour under strange conditions – very easy to test for sturdines against idiocy - (pro)
  10. You quickly learn to love it (pro)

So there you have it, four cons versus five pros. I guess unit testing actually is good and I am forced to somewhat eat my words … but I still think it should be easier to do integration testing. Sure, very easy to mimick an input straight to an object. But how on earth can you test an application actually reads input as expected?

Or, how exactly do you test the output of something? Just because all the return values are correct, doesn’t mean the actual output is as well. And what about GUI’s? I would love to have a way of testing my GUI looks like I expect it to without having to keep reruning the application … ideally, unit testing would be so good that after the tests pass I can be certain everything works and ship it without ever having run what I’m working on. But I don’t think we’re getting that any time soon.

Reblog this post [with Zemanta]
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. You can leave a response, or trackback from your own site.

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
 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
 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

Leave a reply

Name (*)
Mail (will not be published) (*)
URI
Comment