Unit Testing

I l @ ve RuBoard

In the past, bug hunting was done by testers and once the bug was discovered the programmer would remove the offending syntax. Now XP puts the primary responsibility back on the programmer for finding the bug that she created, through automated testing and build management. Quality assurance still has a major role in the testing process, but it is more "assurance" than babysitting .

Automated testing is done with unit tests. These are small programs that allow programmers to test methods in their object code on a pass/fail basis. Unit tests exist for almost every language. Here is how they work.

XP makes the programmer responsible for finding and eliminating any bugs he created.

Before writing a single line of code, a programmer working on a story first writes a test for the function being created, in the same language she is using to write the program. The test needs to describe what the function will do. If the code doesn't perform its method correctly, it fails; if it does perform correctly, it passes . Very simple, but in this simplicity lies the cornerstone of all XP practices.

As systems get larger, they become brittle because a single change in one place can wreak havoc in others. The connections between objects become difficult to retrace as systems grow, and eventually touching any part of the code strikes fear into programmer's hearts. Refactor this code? Just try not to add four bugs for each one you remove and you are ahead of the average. If you are a manager, just try to get a programmer to take responsibility for code that someone else wrote.

Imagine the same system but with a unit test for each public method. Now when you make a change, you can see immediately where something has broken. You can tear out code and new methods without fear. The simple practice of unit testing extends the life of a system, uncouples the code from its author, and allows you to make code better over time instead of leaving it to decay.

XP is light on documentation. It can get away with this primarily because unit tests are the best documents you could ask for. Their parameters define perfectly the nature of the code, and the descriptions of how code can fail inherently describe how to make it pass in the simplest way.

I l @ ve RuBoard