Noel Rappin - Rails 4 Test Prescriptions: Build a Healthy Codebase

Copyright 2014 The Pragmatic Programmers, LLC. This book is licensed tothe individual who purchased it. We don't copy-protect itbecause that would limit your ability to use it for yourown purposes. Please don't break this trust-don't allow othersto use your copy of the book. Thanks.
- Dave & Andy.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC.

Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein.

Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://pragprog.com.

The team that produced this book includes: Susannah Davidson Pfalzer (editor), Potomac Indexing, LLC (indexer), Candace Cunningham (copyeditor), Dave Thomas (typesetter), Janet Furlow (producer), Ellie Callahan (support).

For international rights, please contact .

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher.
Printed in the United States of America.
ISBN-13: 978-1-941222-19-5

Book version: P1.0December 2014

Its been six years since I first started working on a book called Rails Test Prescriptions. In that time, many people have helped me make this book better than I could have made it on my own. This includes but is by no means limited to the following people.

Without the encouragement of Brian Hogan and Gregg Pollack, this might still be a self-published book. Brian also provided a valuable review of this edition.

Lynn Beighley has been my editor on this version of the project and has shaped the material this time around. Ive worked with Susannah Pfalzer on all my Pragmatic projects, and shes always been helpful and great to work with.

Many technical people reviewed this book and had their commentsincorporated. They include Liz Abinante, Ashish Dixit, Mike Gehard,Derek Graham, Avdi Grimm, Sean Hussey, John Ivanoff, Evan Light, MyronMarston, Kerri Miller, Tim Morton, Matt Rohrer, Nell Shamrell, BrianVan Loo, and Andy Waite.

Ive been very fortunate to be working at Table XI while writing this book. Not only have they been very supportive of the project; Ive also had the chance to get insights and corrections from my very skilled coworkers.

This book is a commercial product built on the time and generosity of developers who create amazing tools and release them to the world for free. Thanks to all of you.

My family has always been encouraging. Thanks to my children, Emma and Elliot, who are more amazing and awesome than I ever could have hoped. And thanks to my wife Erin, the best part of my life and my favorite person. I love you very much.

Test-driven development, or TDD, is the counterintuitive idea that developers will improve both the design and the accuracy of their code by writing the code test-first. When adding new logic to a program, the TDD process starts by writing an automated test describing the behavior of code that does not yet exist. In a strict TDD process, new logic is added to the program only after a failing test is written to prompt the creation of the logic.

Writing tests before code, rather than after, allows your tests to help guide the design of your code in small, incremental steps. Over time this creates a well-factored codebase that is easy to change.

Well apply the TDD process to the creation of applications using Ruby and Rails. Well talk about how to apply TDD to your daily coding and about the tools and libraries that make testing in Rails easier.

But first let me tell you a story.

Imagine two programmers working on the same task. Both are equally skilled, charming, and delightful people, motivated to do a high-quality job as quickly as possible. The task is not trivial but not wildly complex either; for the sake of discussion, lets say its a new user logging in to a website and entering some detailed pertinent information.

The first developer, who well call Sam, says, This is pretty easy, and Ive done it before. I dont need to write tests. And in five minutes Sam has a working method ready to verify.

Our second developer is named Jamie. Jamie says, I need to write some tests. Jamie starts writing a test describing the desired behavior. The test is executable and passes if the corresponding code matches the test. Writing the test takes about five minutes. Five additional minutes later, Jamie also has a working method, which passes the test and is ready to verify. Because this is a fable, we are going to assume that Sam is allergic to automated testing, while Jamie is similarly averse to manually verifying against the app in the browser.