Page 238 -

8.2 Test-driven development 221

Of course, I have simplified the sequence diagram in Figure 8.8 so that it does not
show exceptions. A complete use case/scenario test must also take these into account
and ensure that objects correctly handle exceptions.
For most systems, it is difficult to know how much system testing is essential and
when you should to stop testing. Exhaustive testing, where every possible program
execution sequence is tested, is impossible. Testing, therefore, has to be based on a
subset of possible test cases. Ideally, software companies should have policies for
choosing this subset. These policies might be based on general testing policies, such
as a policy that all program statements should be executed at least once.
Alternatively, they may be based on experience of system usage and focus on testing
the features of the operational system. For example:

1. All system functions that are accessed through menus should be tested.
2. Combinations of functions (e.g., text formatting) that are accessed through the
same menu must be tested.
3. Where user input is provided, all functions must be tested with both correct and
incorrect input.

It is clear from experience with major software products such as word processors
or spreadsheets that similar guidelines are normally used during product testing.
When features of the software are used in isolation, they normally work. Problems
arise, as Whittaker (2002) explains, when combinations of less commonly used fea-
tures have not been tested together. He gives the example of how, in a commonly
used word processor, using footnotes with a multicolumn layout causes incorrect
layout of the text.
Automated system testing is usually more difficult than automated unit or compo-
nent testing. Automated unit testing relies on predicting the outputs then encoding
these predictions in a program. The prediction is then compared with the result.
However, the point of implementing a system may be to generate outputs that are
large or cannot be easily predicted. You may be able to examine an output and check
its credibility without necessarily being able to create it in advance.

8.2 Test-driven development

Test-driven development (TDD) is an approach to program development in which
you interleave testing and code development (Beck, 2002; Jeffries and Melnik,
2007). Essentially, you develop the code incrementally, along with a test for that
increment. You don’t move on to the next increment until the code that you have
developed passes its test. Test-driven development was introduced as part of agile
methods such as Extreme Programming. However, it can also be used in plan-driven
development processes.