Introduction

This appendix reviews the essential rules and practices of Extreme Programming (XP), focusing in more detail on the quality aspects of the method.

The XP rules and practices are grouped into four sections: (1) planning, (2) designing, (3) coding, and (4) testing. It is notable that in virtually every description of the principles of XP you read, you will find that testing is covered last. In this appendix, testing is covered as the first topic.

Testing

Quality assurance (QA) is considered to be an essential aspect of XP. QA may be performed by a separate group, or it can be integrated into the development team itself. In either case, XP promotes the idea that the developers have a high degree of contact with the QA group; this is very much in line with the XP philosophy of closer communications between the stakeholders in a project.

XP provides some excellent guidance on testing:

• XP encourages early and frequent testing.

• XP looks to make the process as efficient and effective as possible by promoting the use of test automation.

• XP demands that all code have associated tests, and that where code is changed that the tests be rerun (and/or modified where appropriate to reflect the changes).

• XP requires test design to be completed before coding has started, with all code having associated unit tests.

There are just two types of test in XP:

• Unit tests written by the developers to test their code. These are white box tests [4], which rely on the knowledge of the code and its purpose.

• […]