Nothing Left to Chance
A pair of books from a pair of pragmatic programmers tackle source code control and testing programmatically.
I don't know about you, but destroying the world isn't on my to-do list
for this week. Fortunately, there are ways for us to avoid causing quite
so many accidents. The interesting thing about computer programming is
not that accidents are unavoidable, but that so many of us neglect the
basic, known procedures that help to avoid them.
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.
| Want to read more of Mike's work? Sign
up for the monthly Developer Central e-newsletter,
including product reviews, links to web content, and more,
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.
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
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
- 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
Mike Gunderloy, MCSE, MCSD, MCDBA, is a former MCP columnist and the author of numerous development books.