In Object Thinking, David West reminds us of Christopher Alexander's (the father of patterns) example of "fitness":Alexander points to the task of making a metal face smooth and level. A standard block, smooth and level to a precision greater than required by the target metal face, is inked and rubbed against the target. The presence or absence of ink on the target indicates high and low spots that need to be reground.
This is a great example of testing.
The standard block is the test code. The block defines the "shape" of the resulting code. The imperfections that exist in the block will be duplicated in the production code. The time spent perfecting the standard block is time spent perfecting both the test and the production.
The standard block can't be produced in the same way as the production plate as that would require another standard block. A test can only really be tested by inspection.
Pressing the standard block against the plate is performing a test, but the method of applying ink to the block is the realisation of a test report. The ink reports not only that there is a problem, but also pinpoints what the problem is and where it exists. It guides the tester to the place where work is needed. Every test has to give you an indication of overall success or failure, but a good test gives you a clear guide to the cause.
The rig that presses the standard block to the plate is the test setup and teardown. It allows the test to be repeated easily, ensuring that the standard block is level when it's pressed against the plate. This makes sure that all the ink that's on the block is on there because of a test failure rather than a difference in the way the test was performed.. There's no ambiguity in the results; patches of ink means failure.
Adding a process that takes every production plate and presses an inked standard block against it, detecting the ink on the production plate automatically would be the implementation of automated testing.
It's a repeatable test; it gives clear indication of success or failure; it guides you to the problem if a failure exists; it can be easily embedded within an automated process.
Another good reason why it's a great test:
Whilst it tells you what the problem is and guides you towards
a solution, it doesn't tell you what method you should use to implement that solution.