By Ben Rady and Rod Coffin
(Pragmatic Bookshelf, $33.00, paperback)
I used to test software for a living. It was seldom a pretty sight.
Patches to customized software sometimes would be released to particular customers on an emergency basis. Then I would be asked to test what had just been shipped.
Often, I found bugs — serious bugs. And often, it was Friday afternoon, and the programmers had gone home. Frequently, I had no idea which customer had received the buggy patches, and I had no way to fix the code myself and issue a new release.
So the customers installed bad software over the weekend and quickly called in to complain. But the software development manager had my report. So the programmers then were lashed until morale improved, as the old saying goes. A new load was created — and this time tested before it was shipped to the customer, along with profuse apologies (and who knows what else) by the sales department.
To murder an old saying, this was no way to run a software railroad.
The book, illustrated with code examples and screen shots, shows how to set up and maintain a quick and powerful test suite and also how to use inline assertions and other continuous-testing (CT) techniques, rather than old-fashioned debugging or printing out piles of paper so you can search frantically for that missing semicolon or extra parenthesis.
The chapter line-up shows the topic focus in each part.
- Chapter 1: Why Test Continuously?
Part 1 — Ruby and Autotest
- Chapter 2: Creating Your Environment
- Chapter 3: Extending Your Environment
- Chapter 4: Interacting with Your Code
- Chapter 5: Testing Rails Apps Continuously
Part III — Appendices
- Appendix 2: Gem Listing (This is a listing of all the gems installed while testing the book’s examples.)
- Appendix 3: Bibliography
The goal of the book is to show you how to use a combination of techniques, tests and tools to catch software problems while you are initially coding, not later in the process when you’re up against the wall of develpment and delivery deadlines.
“A continuous testing environment validates decisions as soon as we make them,” the authors state. “In this environment, every action has an opposite, automatic, and instantaneous reaction that tells if what we just did was a bad idea. This means that making certain mistakes becomes impossible and making others is more difficult. The majority of the bugs that we introduce into our code have a very short lifespan. They never make their way into source control. They never break the build. They never sneak out into the production environment. Nobody ever sees them but us.”
Sounds good to this ex-software tester! (Although I do remain suspicious of the word “never” in anything related to software.) Sure wish the programmers in my groups had had these tools.
“Continuous testing is our first line of defense,” the authors point out. “Failure is extremely cheap here, so this is where we want things to break down most frequently.”
They also describe some drawbacks and limitations to continuous testing and ways to blend CT with continuous integration, before moving into the coding and testing examples.
The authors “suggest” using the follow to run the examples in this book:
- A *nix operating system (such as Linux or MacOS)
- Ruby 1.9.2
- Rails 3.0.4
The book provides a link to online source for the coding examples.
“The examples may work in other environments (such as Windows) and with other versions of these tools,” they add, “but this is the configuration that we used while writing the book.”
— Si Dunn