Extreme Programming (XP) is defined in terms of values and practices. In Part II we explore the practices half of the XP equation. We first explore testing, one of the most fundamental practices, in great depth. We then explore some proposed new practices and extensions to current practices. We begin with an overview of testing by Don Wells in Chapter 9.
Chapters 10 and 11 are written from a quality assurance (QA) point of view. There are many advantages to including the QA department as an integral part of an XP team. The XP requirement of acceptance tests directly reinforces it. First, Lisa Crispen asks the question, "Is quality negotiable?" She answers this and other questions that arise when customer requirements do not include standards of quality. There is a difference between internal quality, which is controlled by the developers, and external quality, which should be driven by customer needs. Quality from a customer's perspective is what happens when your user does something unexpected. Quality is about filling in all the unknowns in the product specification. Quality is about the compromise between new features and well-defined behavior. Lisa Crispen describes why and how to negotiate external quality with customers in Chapter 10.
The collaboration between developers and QA members of the XP team is explored by Michael Silverstein and Mark Foulkrod. The primary job of QA on an XP project has always been to write acceptance tests. Chapter 11 explores the idea that QA may be involved in additional support activities. Increasing the robustness of unit test suites is one such activity. But for QA to become more involved, some compromises must be made. Testers do not always have coding abilities sufficient for using bare-bones unit testing frameworks like JUnit. Suggestions for collaboration between QA and developers are explored, and the requirements for a framework that would allow both developers and testers to contribute to unit testing are outlined.
Shaun Smith and Gerard Meszaros further explore unit testing in Chapter 12. Unit testing with databases and enterprise information sources poses some unique problems. One problem that XP teams often must deal with is the requirement of running tests very often. These tests must run quickly. Some ideas for speeding the execution of unit tests are explored.
In a test-first environment, how do we choose which test to implement next? Allen Parrish, Joel Jones, and Brandon Dixon explore a simple algorithm for ordering a set of tests to maximize the impact of each test on the evolution of the code as it matures. A detailed example of how this works is given in Chapter 13. The authors make a good case for not ordering tests in an ad hoc way.
Once your tests have been created, they need to be maintained. Arie van Deursen, Leon Moonen, Alex van den Bergh, and Gerard Kok present many refactorings targeted specifically for unit test code. "Code smells" are specific things to look for as a symptom of something that needs refactoring. The first half of Chapter 14 introduces many code smells specific to unit test code. Each code smell is also associated with a general refactoring or a test-specific refactoring introduced in the second half of the chapter. Together, the two sections form a broad basis for efficiently refactoring unit test code.
Testing is just one form of feedback. XP thrives on feedback, and that means measurements. Christian Wege and Martin Lippert explore the application of metrics to measure the effects of aggressive unit testing and refactoring in Chapter 15. They use historical data from an actual project to demonstrate how their metric can be applied and to validate their hypothesis. As you will see, they apply this metric to look for potential improvements in the project's process.
In Chapter 16 Julian Higman, Tim Mackinnon, Ivan Moore, and Duncan Pierce address the intensity of working on an XP project. After two years they found that complete immersion in this environment could lead to a decline in personal satisfaction. Everything is by the team, for the team. They became focused on sustaining their project velocity. They seemed to be losing a personal sense of accomplishment. Another problem results from a tight focus on customer goals. Without time to explore, they lost touch with current technologies that could be incorporated into the project. And third, they found that doing spike solutions to get better story estimates often delayed the start of an iteration. The "Gold Card system" was introduced at Connextra to address these issues on XP projects.
The concept of Design by Contract was originally explored by Bertrand Meyer. At first glance it may seem incompatible with an agile methodology such as XP, but Hasko Heinecke and Christian Noack explain why it could be beneficial to combine them. The controversial idea of scaling XP up to a large team could justify the use of Design by Contract. And although Design by Contract does not contradict XP, there may very well be a more positive statement to make about the synergy of contracts and unit tests. Chapter 17 is a convincing argument in favor of combining XP with Design by Contract.
A "cost of change" curve that rises slowly over time, as proposed for XP, has been a very controversial idea. Does this also mean a change in the cost of fixing bugs? Under what conditions would the "cost of change" curve be difficult to keep low? Pascal Van Cauwenberghe addresses this question in Chapter 18.
Incremental change is different from refactoring. Refactoring is intended to make no computationally noticeable change. Incremental changes add new functionality or change the program in recognizable ways. Václav Rajlich explores a methodology for incrementally changing a program's functionality. The problem is how to propagate those changes throughout the program while avoiding the introduction of subtle errors. Chapter 19 explores such a methodology and includes a case study of a small Java application to illustrate the problem.
Maintaining legacy code is not considered by most as exciting as new development. Programmers in such a situation tend to have low morale and motivation. But does it have to be that way? Charles Poole and Jan Willem Huisman explore the application of XP techniques to exactly this circumstance in Chapter 20. A short history of the Orbix Generation 3 project and how they were able to introduce XP is reported. Their findings are backed up with some metrics taken from the project.
