What we are aiming for when we are creating tests is to have something that we can rely on to catch the mistakes that we will inevitably make.
This means that we need:
Sufficient tests. All important classes should be tested. Classes that aren't tested are classes that could contain bugs.
Test your code as your add it. Waiting until you have completed a feature or module before testing it is not the correct way to work. If you add a method to a class, then don't consider that method to be complete until you have also added a test that tests that method. You don't want to be in the situation where you finally get around to adding the tests, and then discover that they all fail because you have bugs in a bunch of different methods that you wrote a week ago.
Comprehensive tests. The more comprehensive the tests are, the more that we can rely on them to catch our mistakes.
Tests that run quickly. We want to be able to test our code any time we make a change --- that way if a test fails, we know exactly what we did to cause that test to fail. If the tests take a long time to complete then we will only run them once or twice a day which increases the amount of changes that have to be checked to determine which one caused a test to fail.
Tests that work without needing manual configuration changes. If we have to fiddle with something to put the system into "test mode" then we are not going to run the tests as often as we should. The test code itself should configure the system for testing --- we should not need to modify any code or configuration files before running the tests. We will show you how to do this in the next lab, and lab 10.