Nothing Left to Chance

A pair of books from a pair of pragmatic programmers tackle source code control and testing programmatically.

• By Mike Gunderloy
• 01/01/2004

Which brings me to the subject of this month's column: a pair of new books from Andrew Hunt and David Thomas, the pragmatic programmers (http://www.pragmaticprogrammer.com/index.html). If you have a long enough memory, you may recall that I reviewed their first book, The Pragmatic Programmer, in July 2001. [Note: You can read that article and others in The Skillful Developer, a compilation of Mike Gunderloy's writings for MCP Magazine. Click here for more info.—Editor] Now they're back with two new books on their own imprint: Pragmatic Version Control Using CVS and Pragmatic Unit Testing in Java with JUnit. This pair of slim volumes (about 150 pages each) offer advice on two of the best ways to get your own development practice under control. (A third book on build automation, scheduled for 2004, will complete the "Pragmatic Starter Kit Series.")

Control Your Versions
The first of these volumes is on the practice of version control. Pretty much every developer knows by now that version control when writing software is important—yet some developers still skip this basic practice. The pragmatic guys have no patience for that; they simply say that version control is mandatory on all projects that they're involved with. Having someone impose version control is a pretty good way to deal with developers who are just too lazy or disinterested to bother.

But they go on to point out another way in which version control systems fail: "when pushed most teams complain that version control is just too complex." They may understand the basics of checking files in and out, but the notion of branching, tagging, or creating a release, let alone handling third-party libraries and non-code artifacts (like documentation and build scripts) is just too much for them. "Frustrated, the team either stops using version control, or they bog themselves down with page after page of obscure procedures."

It is this group to which this book is largely directed. After going over the basic theory and vocabulary of version control, Hunt and Thomas present a series of "recipes" for doing various things: ignoring files, renaming files, merging fixes from a branch back to the main development trunk, and so on. Their goal is not to explain (or use) the entire syntax of CVS, their chosen version control system. Rather, they try to come up with a reasonably small set of tasks that will cover most things that the average development team will need to do, and provide clear instructions for those tasks.

This approach is both the strength and weakness of this book. If you're using CVS, the authors' chosen system, you're in luck; you can use the book as a reference for most anything you'll need to do. If you're using some other version control system, the recipes will not be especially useful. There is still content here to help you out: The discussion of what to put under source control, how to develop an effective branching strategy, and how to handle third-party libraries is general and valuable. You can buy the book in PDF format for $20, so even fifty or so pages of useful information can be worth it.

I have some other quibbles as well: The discussion of what a command prompt is seems out of place (I can't imagine any developer being ready to use version control but not understanding a command prompt), and the authors are too quick to defend the edit-commit-merge non-locking style of version control without acknowledging that the lock-edit-commit-unlock style works as well. But those are minor details that don't detract much from a useful book.

Testing Again
The second of these books is about the art and usefulness of unit testing. The authors start by explaining the practice of unit testing with some examples, and then go on to discuss the excuses that they hear from people who don't believe they should be following this practice. Some of these are rather humorous ("It's not my job to test my code. Now here's an interesting excuse. Pray tell, what is your job, exactly?"), but the point is clear: Unit testing saves time and results in higher quality code, so there is not any good excuse to avoid it.

That's all well and good, but the value of this book lies not in convincing people that unit tests are good things, but in showing how to effectively unit test your code. After explaining the mechanics of testing Java code with JUnit, Hunt and Thomas help you think about what you should be testing and which boundary conditions are likely to hide bugs. Then comes an extremely valuable chapter on mock objects, what they are, and how to use them to craft solid tests for code with external dependencies.

The authors discuss the properties of good tests, how to structure a project so as to make unit testing easy, and even how to design for testability. For example, they show how refactoring a GUI-based application so that business logic isn't tangled in the UI code makes it much more amenable to unit testing.

Like the version control book, the unit testing book is anchored in a particular language and tool; the code here is all Java, and the unit tests all depend on JUnit. That's less of an issue than it is with the version control book, though, simply because most unit-testing tools out there are descendants of JUnit. The tasks of unit testing and the strategies involved are much the same whether you're using JUnit, NUnit, or some other unit-testing tool.

Of the two books, I suspect this one will be useful in more organizations than the version control book. Version control has a petty wide penetration, but unit testing is still "out there" for many development organizations. If you're looking to introduce a culture of unit testing at your job, this might be a short enough read to convince your manager that it's worth trying out.

To Read or Not To Read?
So, should you invest your scarce dollars in these books? It depends, I think, on where you are in your development career:

• If you're not using version control at all, run out and buy the version control book. Similarly, if I haven't already convinced you to try unit testing, get the unit testing book and see if the authors can do a better job.
• If you understand the basics but just can't find time to learn more, you still need to get these books. If your version control knowledge consists of checking files in and out, this one will get you up to speed on branching, tagging, and merging, which are all essential skills. If mock objects are a mystery to you and you don't understand how to test a program with a GUI, then the unit testing book will move you along as well.
• If you're a complete pro in either field, you might want to skip the corresponding book, unless you need something to give to subordinates as an introduction to good development practices.

In any case, these two volumes are a good contribution to the literature of practical software development. I'm glad that I took the time to read them, and I picked up a few new ideas to help in my own development work. Can't expect much more from a book than that.

Read any good development books lately? Want to present the case that version control and unit testing aren't really mandatory? You can get hold of me at [email protected]. I'll use the most interesting comments in a future issue of Developer Central.