How to use the right amount of unit tests.

Unit testing is a good idea. Ask any random developer what they think about unit testing and you’re likely to get one of four responses:

  1. I don’t know what they are.
  2. I love them! You should always use them!
  3. I hate them! You should never use them!
  4. I appreciate them, but I’m lazy and don’t use them that much.

Of these, I have the most respect for the first and fourth. If you don’t know what unit testing is, you can hardly be blamed for failing to employ them. Go learn more about them and maybe you’ll enjoy the rest of this entry a bit more. If you are familiar with them but feel that you don’t use them enough, don’t beat yourself up. You’re probably using them “about the right amount.” That is to say, as much as you need to, in order to alleviate your pains.

Groups 2 and 3 could practically be folded into one, because each is about as useless as the other. Some things in life demand a strict behavioral code, but programming is not one of them. Some kinds of code bases and programming tasks are extremely conductive to unit testing, and others are not. Use them wherever they make sense, and where they accelerate your ability to improve upon your existing code base. I won’t go into much more about the whens and ifs, but Wil Shipley and Bill Bumgarner have delved deeper into this question, if you’re interested in reading more.