Java Reference
In-Depth Information
In PutTakeTest , we compute the checksum of elements added to and removed from the
queue and combine these checksums across all the threads, but this could still be optimized
away if we do not actually use the checksum value. We happen to need it to verify the cor-
rectness of the algorithm, but you can ensure that a value is used by printing it out. However,
you should avoid doing I/O while the test is actually running, so as not to distort the run time
measurement.
A cheap trick for preventing a calculation from being optimized away without introducing
too much overhead is to compute the hashCode of the field of some derived object, com-
pare it to an arbitrary value such as the current value of System. nanoTime , and print a
useless and ignorable message if they happen to match:
The comparison will rarely succeed, and if it does, its only effect will be to insert a harmless
space character into the output. (The print method buffers output until println is called,
so in the rare case that hashCode and System.nanoTime are equal no I/O is actually
performed.)
Not only should every computed result be used, but results should also be unguessable.
Otherwise, a smart dynamic optimizing compiler is allowed to replace actions with precom-
puted results. We addressed this in the construction of PutTakeTest , but any test program
whose input is static data is vulnerable to this optimization.
12.4. Complementary Testing Approaches
While we'd like to believe that an effective testing program should “find all the bugs”, this is
an unrealistic goal. NASA devotes more of its engineering resources to testing (it is estimated
they employ 20 testers for each developer) than any commercial entity could afford to—and
the code produced is still not free of defects. In complex programs, no amount of testing can
find all coding errors.
The goal of testing is not so much to find errors as it is to increase confidence that the code
works as expected. Since it is unrealistic to assume you can find all the bugs, the goal of a
quality assurance (QA) plan should be to achieve the greatest possible confidence given the
testing resources available. More things can go wrong in a concurrent program than in a se-
quential one, and therefore more testing is required to achieve the same level of confidence.
So far we've focused primarily on techniques for constructing effective unit and performance
Search WWH ::




Custom Search