Java Reference
In-Depth Information
functional tests. We put functional unit tests in our scope because they're often use-
ful as part of the battery of tests run in development.
forge.net/)
, which provides functional unit testing of the runtime Struts configura-
tion. These tests tell a developer that the controller is invoking the appropriate
software action and forwarding to the expected presentation page, but they don't con-
firm that the page is present and renders correctly.
Having examined the various types of unit tests, we now have a complete picture
of application testing. We develop with confidence because we're creating tests as we
go, and we're running existing tests as we go to find regression bugs. When a test fails,
we know exactly what failed and where, and we can then focus on fixing each prob-
lem directly.
4.3
Black box versus white box testing
Before we close this chapter, we focus on one other categorization of software tests:
black box and white box testing. This categorization is intuitive and easy to grasp,
but developers often forget about it. We start by exploring black box testing, with
a definition.
DEFINITION
Black box test
—A black box test has no knowledge of the internal
state or behavior of the system. The test relies solely on the external system
interface to verify its correctness.
As the name of this methodology suggests, we treat the system as a black box; imagine
it with buttons and
LED
s. We don't know what's inside or how the system operates. All
we know is that by providing correct input, the system produces the desired output.
All we need to know in order to test the system properly is the system's
functional speci-
fication
. The early stages of a project typically produce this kind of specification, which
means we can start testing early. Anyone can take part in testing the system—a
QA
engineer, a developer, or even a customer.
The simplest form of black box testing would try to mimic manually actions on the
user interface. Another, more sophisticated approach would be to use a tool for this
task, such as
HTTPU
nit,
HTMLU
nit, or Selenium. We discuss most of these tools in the
last part of the topic.
At the other end of the spectrum is white box testing, sometimes called glass box
testing. In contrast to black box testing, we use detailed knowledge of the implemen-
tation to create tests and drive the testing process. Not only is knowledge of a compo-
nent's implementation required, but also of how it interacts with other components.
For these reasons, the implementers are the best candidates to create white box tests.
Which one of the two approaches should you use? Unfortunately, there's no cor-
rect answer, and we suggest that you use both approaches. In some situations, you'll
need user-centric tests, and in others, you'll need to test the implementation details of
the system. Next, we present pros and cons for both approaches.
