Refactoring and Testing
If XP ultimately goes the way of the Pet Rock, one aspect that is sure to stick is refactoring. Refactoring refers to a group of codified techniques used to identify and improve bad code written by the other guy and occasionally by the programmers themselves (programmers will always be referred to in the plural in the world of pair programming). It relies on unit tests to maintain confidence that the refactoring has not broken something else and small incremental changes.
In the first example in his book, "Refactoring: Improving the Design of Existing Code" (Addison Wesley Longman, 1999), Martin Fowler decomposes one "smelly" method in one class into a total of 10 methods spread over seven classes. He goes so far as to bad-mouth comments in code, one of the first rules of Programming 101. While refactoring makes a lot of sense, so did comments, designing for reuse, and separate modular programming just a few months ago. It makes me wonder if we'll be reading "Defactoring" in a few years with an example of how to combine everything back into one method.
While XP is quite specific about unit testing of code at the method and class level, it is a bit vague about other testing. It does require (XP doesn't recommend anything) a tester on the project. XP advocates functional testing by customers and/or users to make sure new releases produce the same answers, but it does so with far less zeal than unit testing. XP also gives short shrift to GUI testing, stress testing, and testing in multiple platforms. These can be difficult, time-consuming activities and are often difficult to automate. These tests can also create a large overhead in an environment that advocates frequent releases. But most managers recognize these are high-risk areas that can make or break a software project.