In this chapter, we have looked at test code from the perspective of refactoring. While working on our XP project, we observed that the quality of the test code was not as high as the production code. Test code was not refactored as mercilessly as our production code, following Fowler's advice that it is OK to copy and edit test code, trusting our ability to refactor out truly common items later [Fowler1999, p. 102]. When at a later stage we started to refactor test code more intensively, we discovered that test code has its own set of problems (which we translated into smells) and its own repertoire of solutions (which we formulated as test refactorings). The contributions of this chapter are the following.
The purpose of this chapter is to share our experience in refactoring test code of our ongoing XP project with other XP practitioners. We believe that the resulting smells and refactorings provide a valuable starting point for a larger collection based on a broader set of projects. Therefore, we invite readers interested in further discussion on this topic to the C2 Wiki.[3]
An open question is how test code refactoring interacts with the other XP practices. For example, the presence of test code smells may indicate that your production code has some bad smells. So trying to refactor test code may indirectly lead to improvements in production code. Furthermore, refactoring test code may reveal missing test cases. Adding those to your framework will lead to more complete test coverage of the production code. Another question is at what moments in the XP process test refactorings should be applied. In short, the precise interplay between test refactorings and the XP practices is a subject of further research. |