Page 87 -

70 Chapter 3 Agile software development

Test 4: Dose Checking
Input:
1. A number in mg representing a single dose of the drug.
2. A number representing the number of single doses per day.

Tests:
1. Test for inputs where the single dose is correct but the frequency is too high.
2. Test for inputs where the single dose is too high and too low.
3. Test for inputs where the single dose × frequency is too high and too low.
4. Test for inputs where single dose × frequency is in the permitted range.
Figure 3.7 Test case Output:
description for dose OK or error message indicating that the dose is outside the safe range.
checking

The role of the customer in the testing process is to help develop acceptance tests
for the stories that are to be implemented in the next release of the system. As I dis-
cuss in Chapter 8, acceptance testing is the process where the system is tested using
customer data to check that it meets the customer’s real needs.
In XP, acceptance testing, like development, is incremental. The customer who is
part of the team writes tests as development proceeds. All new code is therefore val-
idated to ensure that it is what the customer needs. For the story in Figure 3.5, the
acceptance test would involve scenarios where (a) the dose of a drug was changed,
(b) a new drug was selected, and (c) the formulary was used to find a drug. In prac-
tice, a series of acceptance tests rather than a single test are normally required.
Relying on the customer to support acceptance test development is sometimes a
major difficulty in the XP testing process. People adopting the customer role have
very limited available time and may not be able to work full-time with the develop-
ment team. The customer may feel that providing the requirements was enough of a
contribution and so may be reluctant to get involved in the testing process.
Test automation is essential for test-first development. Tests are written as executable
components before the task is implemented. These testing components should be stand-
alone, should simulate the submission of input to be tested, and should check that the
result meets the output specification. An automated test framework is a system that
makes it easy to write executable tests and submit a set of tests for execution. Junit
(Massol and Husted, 2003) is a widely used example of an automated testing framework.
As testing is automated, there is always a set of tests that can be quickly and eas-
ily executed. Whenever any functionality is added to the system, the tests can be run
and problems that the new code has introduced can be caught immediately.
Test-first development and automated testing usually results in a large number of
tests being written and executed. However, this approach does not necessarily lead to
thorough program testing. There are three reasons for this:

1. Programmers prefer programming to testing and sometimes they take shortcuts
when writing tests. For example, they may write incomplete tests that do not
check for all possible exceptions that may occur.