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.
- Tests are Specs – they define the behavior of the system.
- 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.
- 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.