Page 171 -

Unit testing is an efficient way to build better software. Test-driven development often
yields code that has fewer defects than standard development, and many programmers
who do test-driven development find that they are able to produce that code more quickly
than they had in the past.
Everyone Is Responsible for Quality
In some organizations, there seems to be a growing tension between the programmers and
testers. The testers will find an increasing number of defects, which they feel should have
been caught before the build was delivered to them. The programmers, on the other hand,
start to feel that they aren’t responsible for testing of any kind—not even unit tests—
because they feel the testers should catch every possible problem. Project managers who
start to sense this tension often feel powerless to do anything about it. In situations like
this, automated unit tests can help.
Many programmers are confused about exactly what it is that software testers do. All they
know is that they deliver a build to the QA team. The QA people run the program and find
bugs, which the programmers fix. It is often hard for them to figure out where unit testing
ends and functional testing begins. A good project manager will keep an eye out for this
confusion, and help to clarify it by making sure that the programmers understand what
kinds of testing are expected of them.
There are different kinds of testing that serve different purposes. The purpose of unit tests
is to verify that the software works exactly as the programmer intended. Software testers,
on the other hand, are responsible for verifying that the software meets its requirements
(in the SRS) and the needs of the users and stakeholders (in the Vision and Scope Docu-
ment). Many defects arise when a programmer delivers software that worked as he
intended, but did not meet the needs of the users. It’s the software tester’s job to catch
these problems (see Chapter 8). This is why both the programmers and testers must test
the software—they are looking for different problems. If this distinction is clear to the pro-
grammers, they should understand why unit testing is their responsibility.

By adopting unit tests and test-driven development, the programmers can develop a very
clear picture of exactly what their testing responsibilities are. Before the programmers

deliver their code to QA, the code should pass every unit test. This does not necessarily
mean that the software does what it’s supposed to do, but it does mean that it works well
enough that a tester can determine whether it does its intended job.

It should make intuitive sense that, since the QA team runs the software as if they were
users, they do not have access to the individual units (objects, functions, classes, database
queries, modules, etc.) that the programmers create. If these units are broken, it is often
possible for those defects to be masked, either in the user interface or elsewhere in the
software. Even if those units seem to function properly, there may be defects that will only
be found when those units are used together in complex ways. This is what QA engineers
do—they simulate complex actions that could be performed by the users in order to find
these defects. From this perspective, it is not hard for a programmer to see that only the
programmers can test those units, and that those units must be working before the testers

DESIGN AND PROGRAMMING 163