Page 86 -

3.3 Extreme programming 69

3.3.1 Testing in XP

As I discussed in the introduction to this chapter, one of the important differences
between incremental development and plan-driven development is in the way that
the system is tested. With incremental development, there is no system specification
that can be used by an external testing team to develop system tests. As a conse-
quence, some approaches to incremental development have a very informal testing
process, in comparison with plan-driven testing.
To avoid some of the problems of testing and system validation, XP emphasizes
the importance of program testing. XP includes an approach to testing that reduces
the chances of introducing undiscovered errors into the current version of the system.
The key features of testing in XP are:

1. Test-first development,
2. incremental test development from scenarios,
3. user involvement in the test development and validation, and

4. the use of automated testing frameworks.

Test-first development is one of the most important innovations in XP. Instead of
writing some code and then writing tests for that code, you write the tests before you
write the code. This means that you can run the test as the code is being written and
discover problems during development.
Writing tests implicitly defines both an interface and a specification of behavior
for the functionality being developed. Problems of requirements and interface misun-
derstandings are reduced. This approach can be adopted in any process in which there
is a clear relationship between a system requirement and the code implementing that
requirement. In XP, you can always see this link because the story cards representing
the requirements are broken down into tasks and the tasks are the principal unit of
implementation. The adoption of test-first development in XP has led to more general
test-driven approaches to development (Astels, 2003). I discuss these in Chapter 8.
In test-first development, the task implementers have to thoroughly understand
the specification so that they can write tests for the system. This means that ambigu-
ities and omissions in the specification have to be clarified before implementation
begins. Furthermore, it also avoids the problem of ‘test-lag’. This may happen when
the developer of the system works at a faster pace than the tester. The implementa-
tion gets further and further ahead of the testing and there is a tendency to skip tests,
so that the development schedule can be maintained.
User requirements in XP are expressed as scenarios or stories and the user priori-
tizes these for development. The development team assesses each scenario and
breaks it down into tasks. For example, some of the task cards developed from the
story card for prescribing medication (Figure 3.5) are shown in Figure 3.6. Each task
generates one or more unit tests that check the implementation described in that task.
Figure 3.7 is a shortened description of a test case that has been developed to check
that the prescribed dose of a drug does not fall outside known safe limits.