Interview with xUnit Test Patterns Author and Jolt Productivity Award Winner Gerard Meszaros
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
InformIT: How and when did you get the inspiration to write xUnit Test Patterns, which won the Jolt Productivity Award earlier this year?
Gerard Meszaros: On my first eXtreme Programming project back 2000 we started off doing XP "by the book" using pretty much all the practices including pair-programming, collective ownership and test-driven development. Of course, we had a few challenges figuring out how to test some aspects of the behavior of the application but we were writing tests for most of the code. Then, as the project progressed, I started to notice a disturbing trend; it was taking longer and longer to implement similar tasks. When I dug into what was causing the slowdown I discovered that we were spending up to 90% of the time modifying the existing tests to accommodate relatively minor changes to the code. This was the first major "test smell" we encountered on the project but certainly not the last. We refactored our tests to reduce the duplicated code that was causing the problems and this not only sped up development but made the tests a lot easier to understand. This profound effect kick-started my quest for constantly improving the readability and expressiveness of the tests. Then, talking with other early adopters of Test-Driven Development at the early XP conferences I discovered that they were having similar issues and had come up with a lot of the same solutions. Being a "patterns guy" from way back, I immediately realized that these were "test patterns" and started mentally cataloging them as we used them. After several years of waiting for someone to write the book, my co-worker Shaun Smith and I finally gave up and decided to write the book ourselves. Unfortunately, Shaun had to drop out fairly early on but he encouraged me to continue and provided valuable support to help me get started.
InformIT: Since the publication of xUnit Test Patterns, what type of feedback have you received from the software engineering community?
Gerard: The feedback from the software engineering community has been very encouraging all the way through the writing process. I was publishing my draft material as a website as I wrote and rewrote and I received a lot of valuable feedback. Now that the book has published a lot of people have said something to the effect of, "I wish this book would have been available when I first started writing automated unit tests. It would have saved me a lot of grief!" Yes, quite a few people comment on the size of the book (900 pages) but most acknowledge that the structure (200 pages of narratives with the rest being reference material) makes it easy to read and put into practice.
InformIT: What are the biggest benefits that development organizations can recognize by revamping their unit tests?
Gerard: Well, first of all, they will have automated unit tests to use as a safety net when changing the code (which is inevitable). Most code in existence today has no such safety net, which is why software is often considered "fragile" or "brittle" in that fixing a bug often introduces two more bugs. Having automated tests that can be rerun in a matter of minutes takes a huge burden off the shoulders of the developers and testers.
Secondly, the cost of writing and maintaining those automated unit tests will be greatly reduced. There will be a lot less duplication in the tests, and the tests will be a lot easier to understand. They will exhibit a lot fewer "test smells," those symptoms of problems in the test code such as Unrepeatable Test or Interacting Tests. As a result, the team will be able to develop new capabilities much more quickly and with fewer defects.
InformIT: What are your favorite patterns in this book?
Gerard: Of course, it's hard to pick a single pattern out of a collection of 68 patterns and 153 variations. And I really don't want to encourage readers to go out and find uses for pattern XXX "because it's the author's favorite pattern." Patterns shouldn't be treated like a new hammer. (When you have a new hammer, everything looks like a nail!) To me, the goal is really about moving the level of abstraction of the tests closer to the problem domain and improving the communication between the writer of the test and the reader; think of the poor schmuck who's trying to maintain the code at some point in the future. Tests as Documentation is one of the principles I live by and one of the yardsticks I use to assess each test I write: "How well does this test communicate what the software is supposed to do?" I believe that the biggest lasting contribution this book will make is to establish the vocabulary for talking about the design of the automated tests and make everyone aware of the pros & cons of the various possible solutions to each test automation problem.
InformIT: You do a lot of work helping agile teams get off to a good start. What’s the most common challenge you see in this regard?
Gerard: I think there are two completely distinct classes of problems. One is the project leadership problem and the other is the technical skills problem.
The project leadership problem relates to how one comes up with the definition of what the product is supposed to do and how it will be used. It's not enough to come up with this definition; it also needs to be communicated to everyone on the team and constantly kept at the front of everyones' consciousness. Its all too easy for team members to fall into the "just tell me what to do" mindset, but this results in sub-optimal behaviors that can lead to building the wrong product. I'm often asked to run product definition workshops with the project stakeholders. We conduct a series of exercises to clarify the business need and what the technical solution might look like. We develop artifacts like the Elevator Speech and the Product Box, and we build low-fidelity paper prototypes we can test with potential end users. Only once we've defined the product at a higher level do we come up with the Feature Backlog for the product. Ideally, we'll involve the development team in the whole process so that they have a good understanding of what the business goal is; this prevents building a great technical solution to the wrong problem. I'm one of the first agilistas to incorporate UxD (usability) practices into the agile methodology.
The technical skills problem has several components. Most developers can learn to do Test-Driven Development given enough time, encouragement and training/mentoring. Getting the test automation strategy right is key because most teams have very little experience with automating tests of any kind, let alone unit tests. I work with the team — often in the dual capacity of Agile Coach and Solution Architect — to help them come up with a test strategy appropriate to the product being built. One has to be very conscious of the ROI of the effort spent automating tests because some kinds of test automation are very expensive and don't find/prevent many bugs. The test automation strategy has significant implications for the system architecture, which is why it's important to address it early in the project or product lifecycle. Playing both the Agile Coach and Solution Architect roles has allowed me to inject the necessary design-for-testability into the product architecture.
InformIT: Testing has, obviously, changed a lot in the last ten years and evolved to where it is now slowly becoming the responsibility of each team member. What do you envision for testing in the future?
Gerard: Our software development tools are improving every year. We've seen many of the software refactorings described in Martin Fowler's "Refactoring" book implemented by the IDE vendors. I think testing will get a lot easier over time as the testing tools become more capable and provide direct support for some of the patterns in this book. We've already seen significant advances in the tools for generating Test Stubs and Mock Objects dynamically, making it easier to write tests that take advantage of them. (But beware the new hammer!) A lot of people are thinking about how to test better and how to better integrate automated acceptance testing into the overall product definition and development cycle. Some vendors claim to be able to generate the tests from the software; I'm skeptical as to whether this is actually the right approach, but we'll see sooner or later. I'm hopeful that improvements in the tools will cause our expectations for the minimum level of testing to increase. Two hundred years ago doctors didn't scrub before surgery and reused the same blood-stained apron; now that would be considered criminally negligent. How long will it before handing off untested code will be considered negligent? I'm hoping sooner rather than later. There's less and less of an excuse for that kind of behavior as the tools and practices improve.
InformIT: Where will you be speaking this year?
Gerard: I've already presented tutorials at SD West 2008 and StarEast 2008 as well as a tech talk at Google. My next two major speaking engagements are Agile 2008 in Toronto, Ontario and StarWest 2008 in Anaheim, California. I'm also talking at internal conferences at major software product vendors and to Agile user group meetings, and I'm happy to receive more invitations.
InformIT: Word has it that you’re a fairly avid outdoorsman.
Gerard: Yes, I like to spend a fair bit of time outdoors. In the summer I do a lot of mountain biking and whitewater kayaking. In the winter I do a lot of back-country skiing, which is a cross between downhill skiing and cross-country skiing. But since we spend 90% of our time skiing up the mountain (because we ski where there are no lifts), I jokingly refer to it as "uphill skiing" when asked what kind of skiing I do.