Unit Tests must be FAIR

The following quoted words from the book Programming Groovy are the best description about the quality of Unit Testing that I’ve seen so far, might be useful for my support role as well

Unit Tests must be FAIR

When you write Unit Tests, keep in mind that the tests must be FAIR, that is, Fast, Automated, Isolated and Repeatable.

Tests must be fast. As you evolve your code and refactor, you want to quickly get feedback that the code continues to meet your expectations. If the tests are slow, your developers won’t bother to run them. You want a very quick edit-and-run cycle.

Tests must be automated. Manual testing is tiring, is error prone, and will take your time away from important tasks on which you’re focusing. Automated tests are like angels on your shoulder — they watch you quitely as you write code and whisper in your ears(only) if your code violates set expectations. They give you early feedback if your code begins to fall apart. You’d probably agree that you’d much rather hear from your computer that your code sucks than from your co-worker. Automated unit tests make your look good and dependable. For example, when you say you’re done, you know your code works as intended.

Tests must be isolated. When you got 1,031 compilation errors the usual problem was a missed semicolon, right? That was no helpful; there’s no point in one small error cascading into several reported errors. You want a direct correlation between creeping bug or error and a failed test case. That will help you identify and fix problems quickly rather than being overwhelmed by large failed tests. Isolation will ensure that one test does not leave behind a residual state that may affect another test. It also allows you to run the tests in any order and also to run either all, one, or a select few tests as you desire.

Test must be repeatable. You must able to run the tests a number of times and get deterministic predictable results. The worst kind of test is the one that fails on one run and passes a following run with no change to any code. Threading issues, for example, may bring about some of these issues. As an example, if a test inserts data with unique column numer into database, then a subsequent run of the same test without cleaning up a database will fail. This will not happen, and the test will be repeatable if the test rolls back the transaction. The repeataibility of tests is key to staying in excellent state while you rapidly evolve your application code.