Extreme Programming Installed, Chapters 13-15

Reference Information
Extreme Programming Installed
Jeffries, et al
Addison-Wesley Professional, 2000


Summary
Chapter 13 of Extreme Programming Installed discuses the need for creating unit tests and their constant use throughout the development process. It is the programmer's responsibility to create a test for everything that could possibly break in the system so that any regression in the future will be immediately detected. To facilitate the constant testing, the unit testing system must be completely automated so when a test is added, no further work will be required to have it tested. The framework that the authors suggest is called xUnit, and most languages have their own particular implementation of this framework. The tests should be written before the actual code, with the methods being written in a way so that they are most easily tested, which leads to a cleaner design. Code should only be released when it passes every test that has been written, which will be build the team's confidence that the work they are releasing will function properly.


In chapter 14 the authors further expand upon their ideas about Extreme Programming by stating that code should be written for intention, instead of how it works. That is, code should show what it is doing, not how it is doing it. This allows the code to easily communicate to the reader what is going on without the reader having to be acquainted with the algorithms used. As stated above, code should only be written after the tests for that code. Therefore, code should only be written when there is a failing test. The chapter is dominated by a Smalltalk example that is too large to repeat here and demonstrated the authors' ideas on the subject.


Chapter 15 concerns the process of releasing code to the other programmers on the team and is heavily influenced by collective code ownership. Each programmer being able to work on any piece of code speeds up the development process since he will not have to wait for someone else to fix a problem in their assigned bit of code. Code releasing contains three phases: local, release candidate, and released to the repository. The steps for releasing code are as follows: start with the current code from the repository, write tests for changes, run unit tests, fix any that are broken, when all pass it is called a release candidate, the release candidate is integrated into released code, run tests again, when this passes the code is officially released. Released code is guaranteed to be working. A source control system should be used to help with integration and to increase productivity. Code should be released rapidly, a couple of times per day by each pair of programmers.


Opinion
These chapters, in general, are repeats and elaboration on topics already covered in the book. The most interesting part is the long process from local changes to finally being released into the repository. It seems as though programmers would spend most of their time sitting around waiting for tests to complete. In addition, the book's list of version control systems is severely out-of-date.