Tests are easily reconfigured, replicated, or modified. An example of this is a functional test of a program with a graphical user interface that can be configured to simulate either mouse input or keyboard input. Rather than create different sets of tests to operate in different modes and contexts, design a single test with selectable behavior. Avoid hard-coding basic operations in a given test. Instead, engineer each test in layers and allow its behavior to be controlled from a central configuration file.
Tests are important and unique.
You might think that the best test suite is one with the best chance of finding a problem. So, in a well- designed test suite, for every significant bug in the product, one and only one test will fail. This is an ideal, of course, but we can come close to it. You want one test to fail, at most. Whenever a test fails, you know that at least one thing went wrong, but you can't know if more than one thing went wrong until you investigate.