Unit Tests are the backbone of Agile development. Unit Tests ensure that you are done making a "unit" of a program, that a change or refactoring you have done to a "unit" has not broken the program, and they also help to ensure that you are not over-programming - creating more than you needed to in the wrong place.

I didn't always understand this, but Uncle Bob is probably the best at explaining it when he does The Bowling Game Kata. You should also read Clean Code if you haven't already.

Read Test First:

  1. Tests are Specs - they define the behavior of the system.
  2. Tests are part of the system - The definition of the system's behavior (see #1) makes the system. You don't have a system without the Tests, and you aren't fulfilling the spec without the passing test.
  3. Tests ensure Simple Design - You always write the simplest code to make the spec test pass. You aren't allowed to write more if you're following the "3 Rules of TDD".

Unit Testing isn't a natural thing for me, probably also for you. It is a habit that I have to stay in, and that I have to force myself to conform to. I start out with the idea in my head. I know what I need. Putting it into the form of a test takes extra time I don't have. Or so it seems.

Once I'm in the habit, and I'm working on a codebase that already makes testing easy then the tests get easier to write and the code gets easier to maintain. I think Uncle Bob is right: your software will not look like it was written by a craftsman until you're writing good tests.