At PakNetX, I wrote test tools to support the test automation in the Quality Assurance department. After I'd been working there a year or two, I saw a book by Kent Beck called "eXtreme Programming eXplained". The title intrigued me so I picked it up.

I was amazed by what I read. It talked about ethics as a basis for separating developer and client responsibilities. It treated programming as a social human activity. It pulled together into a cohesive whole a number of elements I had applied at PictureTel - see Farming Software by the Moon for that story - along with a number of elements that were new to me, among them pair programming and unit test frameworks. The latter really intrigued me because I was already familiar with test automation in QA and both from that and from my work at PictureTel I knew how testing combinations of features together produced a combinatorial explosion of test cases. By having developers testing at the individual class level, it could reduce (n times m) tests to (n plus m) tests. I arranged with my management that my next project would also serve as a pilot project for automated unit tests.

The project was small. The sheer number of small projects I did there had already dramatically improved my design skills. As I worked on this one, I learned new techniques. The most interesting classes of a program are almost always the classes that apply business rules to coordinate the work of other classes. If they are tested in place, then the code under test not only includes the interesting code but the code of all the other classes beneath it. I learned techniques like dependency inversion that allowed me to isolate the one class from the frameworks it controls, to measure whether it is calling them and handling their responses correctly. These techniques also exercise hard-to-reach error paths by having the test stubs return error codes or exceptions "from below" for the interesting code to handle.

The pilot project was a success. Not only did it work well, it had a complete suite of test cases that could be applied to future changes, and I was able to write a report outlining how automated unit test worked and the kind of design structures that were necessary for test automation to reach its full potential. This knowledge was vital of the next several years as I applied unit test automation to many existing programs and libraries.