Java Reference
In-Depth Information
Figure 5.1
Partial test coverage with
black box tests
In order to resolve this issue, we need to know precisely what code runs when you or
the build invokes tests. Ideally, our tests should cover 100 percent of our application
code. Let's look in more detail at what benefits test coverage provides.
5.1.1
Introduction to test coverage
Using black box testing, we can create tests that cover the public API of an application.
Because we're using documentation as our guide and not knowledge of the imple-
mentation, we don't create tests, for example, that use special parameter values to
exercise special conditions in the code.
One metric of test coverage would be to track which methods the tests call. This
doesn't tell you whether the tests are complete, but it does tell you if you have a test
for a method. Figure 5.1 shows the partial test coverage typically achieved using only
black box testing.
You can write a unit test with intimate knowledge of a method's implementation. If
a method contains a conditional branch, you can write two unit tests, one for each
branch. Because you need to see into the method to create such a test, this falls under
white box testing . Figure 5.2 shows 100 percent test coverage using white box testing.
You can achieve higher test coverage using white box unit tests because you have
access to more methods and because you can control both the inputs to each method
and the behavior of secondary objects (using stubs or mock objects, as you'll see in
later chapters). Because you can write white box unit tests against protected, package-
private, and public methods, you get more code coverage.
Figure 5.2
Complete test coverage
using white box tests
 
 
 
 
 
 
 
 
 
Search WWH ::




Custom Search