Dave Astels is a very unlikely character. He’s a software consultant that specializes in agile methods, and he’s from Nova Scotia, of all places. I attended one of his talks, which is where I got a free copy of this book, and the talk was a lot like the book — practical, easy to understand, and delivered in extremely basic language.
I learned more from this book than I expected. One of the most valuable lessons I took away was on how to write test fixtures. Astels recommends that you organize test methods into fixtures that allow you to get the maximum reuse out of that fixture. So, instead of having one to hold all the tests for one class, you might instead have a error-situation fixture for that class, and others for various specific purposes. You might also have one that allows you to test a variety of classes or modules in a single common situation. I’ve found that since I started doing this, my test fixtures are harder to name effectively, but are much shorter and much easier to understand. I don’t often dread writing setUp() anymore, because the specific focus of the fixture usually results in it being quite short. Also, because the tests in the fixture are so similar (by virtue of all leveraging the same fixture), you can often refactor the heck out of them, so that they all end up calling a single ‘checker method’ that has most of the asserts in it.
I also picked up a few things on mocks. It turns out that I’ve been calling a lot of things ‘mocks’ that are actually ‘fakes’. What’s the difference? A fake just pretends to be something else. A mock does the same, but it also ensures that it is being used correctly. Astels goes over a bunch of neat ways for generating mocks and stubbing out dependencies in ways that are low-effort and thus extremely useful. The section on writing programmer tests to do basic load testing was very helpful as well. Finally, some of the ideas presented for using TDD to develop a GUI were definitely things I hadn’t thought myself before, and they don’t even look like they’d be all that much work to use.
There are a bunch of things about this book that made me sort of glad that I didn’t actually spend money on it, though. First, it’s way longer than it needs to be. Astels works his way through an entire Java project and includes all the code, which in my opinion is overkill, mostly since the project is so simple. You end up seeing a lot of techniques repeated over and over again. I would have liked to have seen a more complex project presented, with a focus on some of the parts that are traditionally difficult to decouple (e.g. database connections, network connections, other external resource dependencies). Then, there are a whole whack of sections at the end that present unit testing frameworks for other languages, but these are almost completely useless because they only present the aspects of each framework that are similar to JUnit. I would have been much more curious to see the ways in which your approach should differ when working outside of Javaland. For instance, the article on pyunit doesn’t mention that you can’t have a static setUpTestCase or tearDownTestCase like you can in Java, and it certainly doesn’t talk about the added challenges that you encounter in trying to write tests for modules written in a dynamic language. There are important differences, though, when you have a whole extra class of potential errors made possible by the absence of static type checking. This is especially galling because the first unit testing frameworks were written for SmallTalk, which also lacks static type checking.
Finally, Astels’ language and reasoning in most sections errs a little too much on the side of basic. It’s cool at first to feel like you’re chatting with one of your buddies at the bar about hacking together a project using TDD, but it starts to get distracting in parts because it feels like he’s explaining things away instead of just explaining them.
One last complaint. One of the decisions that Astel made in order to make this book ‘relentlessly practical’ was to stick solely to a single platform (Java + JUnit + other associated tools), and many of the specialized tools that he discusses, such as utilities for GUI testing, mock generation, etc., are really only available for Java at the current time (as far as I could tell). So, it’s hard to port the experience you pick up from this book into other languages. (If you happen to be using a language that lends itself to rapid development, though, it certainly might give you the incentive to reimplement some of these ideas in that language, which is always cool!)
So, a fantastic book for people who develop in Java and nothing else, poor souls that they are. Definitely worth a read for the rest of us, but I skimmed heavily and, if you’re not 100% invested in Java, you’ll probably end up doing the same.
Comments (0)