Unit Testing Pros And Cons

"Unit Testing is teh suck" - this post, and some of the comments to it, represent just about every conceivable FUD (fear, Uncertainty, Doubt) about Unit Testing and Test Driven development I've heard, so I'd urge you to go and read that post and especially its comments.

Why?

If you're not sure about Unit Testing, you'll certainly be familiar with some of the fears and doubts mentioned there, which will make you feel better about yourself, but still when you read the comments you'll get a sense that things are not as black and white as they appear to be - Unit Tests could be good for you, or at least they seem to be working just fine on *some* projects out there.

 

If you're pro Unit Testing, have tried it and have failed, you might find yourself agreeing with some of the stuff mentioned there as some of the core reasons why you failed to do Unit Testing with your Project, but it does not have to be this way.

My Upcoming book deals a lot with ways and techniques to make sure that whatever practical problems you face when writing unit tests (Maintaining Unit Tests is very time consuming, Some part of the code are not testable, Not trusting your Unit Tests etc..) are solved to a degree that your Unit Tests "do much more good and much less harm" -- they're worth writing.

Many projects I've seen tried to do unit tests and failed for many reasons:

  1. Tests were written poorly and so would fail or pass intermittently
  2. Changing Tests after changing the API took way too much time so people simply gave up on them
  3. Writing the tests was too hard for the API
  4. Tests took too long to run or required massive amounts of setup to run, so no one ran them and all the bugs were found at once, or bugs could not be detected correctly  - it was "debugging night" all over again.
  5. Management did not approve of taking lots of time to write tests in a Test Driven Manner (political decision, always)
  6. many other reasons.

Most of the problems mentioned here can be solved by implementing some technique to Unit Testing, some of which I've described in this MSDN article, and you can find many others in this series of blog posts in my blog "Testing Guidelines" Category.

"The Art Of Unit Testing" will deal with many of these techniques head on and in deep fasion and not only explain what can be done, but why it's important.

Published Sunday, August 27, 2006 7:21 PM by RoyOsherove
Filed under: , , ,

Comments

Sunday, August 27, 2006 2:03 PM by Andrew Stopford's Weblog

# A very long road

Roy points out Will Shipleys post, Will I have a few things to say.Unit testing will help you write better

Monday, August 28, 2006 2:11 AM by Marlun

# re: Unit Testing Pros And Cons

I'm waiting on your book :)
Monday, August 28, 2006 2:28 PM by Jeff

# re: Unit Testing Pros And Cons

I'm dealing with a lot of that cultural resistance in my current gig. I don't do TDD well enough myself yet to really drive the process. When I was at Progressive, the mandate that you had to work with the Thoughtworks guys to learn to do it the right way was a very good policy.

Monday, August 28, 2006 10:28 PM by Jason

# Unit testing is a design concept just as much or more than it is a testing concept

Unit tests only work well if the developer writing them has a good understanding of object oriented design and the concept of inversion of control. From what I can see most .net developers don't and I believe that's why it hasn't picked up as much in that community as it has others. It's very hard to test some static method on a class that reads its configuration from some predefined location, talks to some hard coded database that has to be available, and calls some web service before returning. I'd give up on that pretty quickly too. As long as a class sticks to a single responsibility and isn't responsible for constructing it's collaborators then creating and maintaining tests is a breeze and perhaps even enjoyable.
Tuesday, August 29, 2006 10:04 AM by David Evans

# re: Unit Testing Pros And Cons

We normally hear 'Why are we writing this twice? The client won’t pay for double the work! I describe it as similar to double entry book-keeping. It looks like double the work but it is just verifying that everything balances. i.e. I expect some code it to do this: +1 (setup), and I verify is has: -1 (assert). When everything balances we have a stable system. If we don’t we just have to ‘hope’ that it all works.
Friday, September 01, 2006 10:58 PM by Brian Broom

# re: Unit Testing Pros And Cons

One obstacle I have noticed personally is that it is difficult to know as a beginner what exactly to test. I have seen (and also written) tests that were almost trivial, to tests that were way too complex. I think one of the major benefits to unit testing is that it can lead to much deeper understanding of the code. As an example, I was recently working on involved subclassing a quirky class in Ruby. Using tests I was able to clearly spell out exactly what I was expecting to happen, and see where it was messing up. Then, instead of blindly doing search and replace type changes, I only changed as much as necessary to get the tests to pass. This showed some subtle differences in some parts of the code, as some things that looked similar required different changes. Before I wrote out the tests, I tried some blind changes, which totally did not work. So in this case its not a case of faster development, but something working where it didn't work before. Looking forward to your material :)