Rails Test Prescriptions: Keeping Your Application Healthy (Pragmatic Programmers) [Paperback]

Testing has been a gap in my Rails practice, and I got this book as part of a concerted effort to close that gap. I had some knowledge of the general options and types of testing that are available to Rails programmers, but like many who had come from other languages and frameworks, I didn't see the immediate necessity to incorporate testing into my work. But the reality is that testing is an important skill in the job market for Rails work, and I decided that I would take it seriously.

First off -- the book does do a creditable job of covering many options, and does a good job of delineating the differences between unit, functional, integration and acceptance testing - although it seems to go out of its way to blur the line between the latter two. Rails' own built-in Test::Unit is given a good introduction, as is what the author calls Controller testing. This is a reasonable name, but not necessarily the one you will encounter among the Rails community, and here is where one of the problems with this book arises.

Mr Rappin is not a gifted writer, and one problem is that his style lurches from conversational, "I remember trying this out" passages, to opaque, technical paragraphs that you may need some time to parse, or simply give up trying. The habit of drawing attention to his preferred naming conventions for things is part of the conversational part of the book that makes it read like course notes for a community college intro course.

And, Mr Rappin has not, it would seem, been granted the help of a top-notch editor. The book is replete with small typos, but more glaringly, with an at times bizarre approach to structure. Topics are frequently introduced without either foregrounding what they are for, or with references to other more advanced topics that are not explained. A good editor would have spotted these problems. The advanced topics of RSpec an Cucumber come up frequently in the context of their alternates, but withot any attempt to put them in perspective.

Examples are spread throughout the book, but the notation of the file they come from or should be inserted into are inconsistent, and sometimes entirely absent. This can be very confusing, especially if you're trying to read the book for an overview, before jumping in to try out the code provided. A good deal of the book is focused on using testing in various ways while developing a hypothetical group collaboration app called "Huddle". But this app is notional only, and a coherent listing that allows you to mark the progress of the development of the app, and see how testing fits in is absent. Even the idea of what Huddle does seems vague and undefined, which is ironic, since Rappin is trying to convince us that testing is an excellent way of defining an application or a feature, allowing us to see clearly what we are trying to achieve before we begin. On reflection, his book ends up being at times a pretty compelling argument against testing - perhaps some irony to be found there.

An example of the this is Rappin's introduction to acceptance testing. Acceptance testing is a powerful technique to clarify for a client what an app is meant to do, and, as Rappin insists at many points, is actually a design method, that precedes the actual writing of code. Rappin does a good job of drumming in the point that the word "test" implies a post-factum process, when in fact the best use of testing is to establish tests that fail, and then write code to satisfy them. But he introduces Cucumber, a testing approach that more than most really needs to precede code, at the end of the book, and in the context of the substantially complete Huddle app. Very strange.

The sections on RSpec are the best, and the overall impression of the book is that RSpec is the most flexible and detailed way to approach Rails app testing, without eliminating the need for things like Model testing. The weakest section is probably that on interface testing, admittedly a difficult subject, because of the underdevelopment of tools, and the ongoing reality that browser compatibility can't be done through testing.

Testing is something of a religious issue in the Rails community. Those who are not among the faithful are often skeptical that testing can really affect bottom-line productivity and accuracy. Rappin makes an anemic case for testing at the opening of the book, with a highly contrived an unconvincing example of how testing may cost you more time at the outset, or on simple projects (a common criticism), but that it "really" saves you tons of time overall. What Rappin, as the testing community in general fails to do, is to provide a convincing metric. Testing is about verifiability, and it seems little to ask that they support their belief with evidence. But again, it is a religious issue, and the demand for proof simply marks you as an apostate, so don't look for that kind of substantial support for testing in this book.

Testing is a rapidly changing field, and writing a book about it is fraught with the problem of obsolescence. Rappin has done a creditable job in this regard, and the book right now is not old enough to have too many glaring differences with reality and current practice. But it will have to be edited and parts rewritten as the field changes, and I hope that then the Pragmatic Programmers series will see fit to edit this book correctly, improve the structure and annotations, and generally bring what is currently a complete but confused mess up to the standard of a very good, clear one. In the mean time, there do not seem to be many published options, so despite its flaws, this may be the book to buy for those interested in incorporating Rails testing.

This is a great book if you're looking to understand:

(A) the various tools that can be used to test all the various parts of a Rails app
(B) how and when to use those tools.

This is a good overview of the "State of the Art", as of publication date, of the various testing technologies for Rails apps. It has good sections on the basic tools that come with Rails (the standard unit testing package and fixtures) including the often overlooked integration tests. Then it's on to the tools which don't come standard; Shoulda, RSpec, and Cucumber. The book does a good job of showing how to use these tools, and gives a thumbnail sketch of their philosophies, so you understand why they were built. The sections on the javascript and view testing tools Jasmine, WebRat and Capybara ("the rodents") are useful pointers towards what can be done with these tools, but it doesn't cover them in the same depth as some of the other tools.

I've found it to be a good tutorial, and a pretty good reference ("How do I set up an RSpec controller test again?"). Highly recommended.

The Rails testing landscape has blossomed far beyond Test Unit, and this book does a good job of describing the current alternatives, giving some background, pros, cons, and how to set up and use each one. Given the frequency with which many developers hop around, this book will prove invaluable in getting you up to speed quickly on whatever tools are being used in your new environment. It will also enable you to make informed decisions to use (or not use) something if you are starting from scratch.

As a final bonus, tech books are notorious sleep-inducers, but Noel has an excellent dry sense of humour that serves to turn this book into a smile-inducer instead.

We are finally realizing how important testing is, which makes this book a must-have for your coding toolbox (and career).