Extreme Programming Installed Ch 13-15

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary
Chapter 13 discussed unit tests, recommending that everything that could possibly break should be tested. Unit tests are automated tests, and they must run perfectly all of the time. Since code is shared, unit tests are necessary to keep the rapid pace of coding working without resulting in broken code. Tests are written from the beginning, and continually written throughout the coding process. Code is only released once all unit tests run at 100%. Tests are created before ever actually writing the code, so sometimes stub methods/objects are necessary if someone else is responsible for the unwritten code.

Chapter 14 discussed the model of testing first by intention. Instead of thinking about how to do something, the programmer should think about what has to be done. This expressed intention instead of the algorithm within the code.

Chapter 15 described the process of releasing changes. It is an important part of making collective code ownership work, so that other programmers on the team can have working code released to them in a timely manner. When a programming pair writes tests and code, once all tests are working 100%, the code should be released to the team's repository. If there are conflicts between revisions, the conflicts should be fixed on an integration machine, where the pair resolves all conflicts, makes sure all unit tests still work completely, then releases the revised code to the repository.


Discussion
This reading is interesting because it brings up some very useful concepts for programming. Unit tests seem as if they would become annoying to the programmer, always having to test every little thing before the code is even written for it. While it seems as if it would be a waste of time, I can see how unit tests would actually be very useful. It probably takes less time to write a unit test than it does to fix large errors that would come up without them. In addition, the discussion about releasing changes was informative, as we are currently using a repository for our project. Some of the suggestions, such as carefully fixing conflicts and releasing very often, are good ideas that we should probably include in our own programming practices.

Source: blog.dileno.com