Now let me conclude the lesson by summarizing a few important
aspects of white-box testing. The first important aspect is that white-box
testing works on a formal model. The code itself are models
derived from the code. So when we do white-box testing, we
don't need to make subjective decision, for example, on the level
of obstruction of our models. Normally, we simply represent what's there.
And so what we will obtain are objective, results and objective
measures. As I also said at the beginning, coverage criteria allows
us to compare different test suites, different sets of tests,
because I can measure the coverage achieved by one test suite
and by the other, and then decide which one to use
based on this measure. And again, remember, these measures aren't perfect,
but they at least give you an objective number, an objective
measure of the likely effectiveness of your tests. So even though
achieving 100% coverage does not mean that you identify all the
problems in the code for sure. If your level of coverage
is 10%, for example, for stemen coverage. That means that
you haven't exercised 90% of your code, and therefore the trouble
is in a piece of software that is inadequately tested
and likely to be of inadequate quality. We also saw that
there are two broad classes of coverage criteria, practical criteria
that we can actually use, and theoretical criteria that are interesting
from a conceptual standpoint, but that they are totally impractical.
They are too expensive to be used on real world software.
And finally, as we also said at the beginning,
one of the great things about white box testing and
coverage criteria, is that they are fully automatable. There are
tools that can take your code, instrument it automatically. And
when you run your test cases, they will tell
you, what is the level of coverage that you achieve
with your test at no cost for you. So there's
really no reason not to measure coverage of your code.