Rails Cookbook

Chapter 7. Rails Application Testing

Introduction

If you cringe at the idea of testing software, then you should think about the alternatives, and what testing really means. Historically, testing was assigned to the most junior member of the team, a summer intern, or even someone who’s not really very good but can’t be fired. It’s not taken seriously. And testing normally doesn’t take place until after the application has been declared “finished” (or some value of finished): it’s often an afterthought that delays your release schedule precisely when you can’t afford any delays.

But it doesn’t have to be this way. Most programmers find debugging much more unpleasant than testing. Debugging is usually what triggers mental images of staring at someone else’s code, trying to understand how it works, only so you can fix the part that doesn’t actually work. Debugging is almost universally accepted as being an unpleasant task. (If you’re thinking that you sometimes get a kick out of debugging, then imagine fixing a bug, only to have it crop up again repeatedly, perhaps with slight variations. The joy of solving the mystery becomes something more like mopping floors.)

The fact that debugging can be unpleasant is exactly what makes testing appealing and, as it turns out, enjoyable. As you build up a suite of tests for each part of your application, it’s as if you’re buying insurance that you won’t have to debug that code in the future. Thinking of tests as insurance helps explain the testing ...