# Learn Web Development with Rails

## Contents

Foreword

My former company (CD Baby) was one of the first to loudly switch to Ruby on Rails, and then even more loudly switch back to PHP (Google me to read about the drama). This book by Michael Hartl came so highly recommended that I had to try it, and the Ruby on Rails Tutorial is what I used to switch back to Rails again.

Though I’ve worked my way through many Rails books, this is the one that finally made me “get” it. Everything is done very much “the Rails way”—a way that felt very unnatural to me before, but now after doing this book finally feels natural. This is also the only Rails book that does test-driven development the entire time, an approach highly recommended by the experts but which has never been so clearly demonstrated before. Finally, by including Git, GitHub, and Heroku in the demo examples, the author really gives you a feel for what it’s like to do a real-world project. The tutorial’s code examples are not in isolation.

The linear narrative is such a great format. Personally, I powered through the Rails Tutorial in three long days, doing all the examples and challenges at the end of each chapter. Do it from start to finish, without jumping around, and you’ll get the ultimate benefit.

Enjoy!

Derek Sivers (sivers.org)
Founder, CD Baby

Acknowledgments

The Ruby on Rails Tutorial owes a lot to my previous Rails book, RailsSpace, and hence to my coauthor Aurelius Prochazka. I’d like to thank Aure both for the work he did on that book and for his support of this one. I’d also like to thank Debra Williams Cauley, my editor on both RailsSpace and the Ruby on Rails Tutorial; as long as she keeps taking me to baseball games, I’ll keep writing books for her.

I’d like to acknowledge a long list of Rubyists who have taught and inspired me over the years: David Heinemeier Hansson, Yehuda Katz, Carl Lerche, Jeremy Kemper, Xavier Noria, Ryan Bates, Geoffrey Grosenbach, Peter Cooper, Matt Aimonetti, Gregg Pollack, Wayne E. Seguin, Amy Hoy, Dave Chelimsky, Pat Maddox, Tom Preston-Werner, Chris Wanstrath, Chad Fowler, Josh Susser, Obie Fernandez, Ian McFarland, Steven Bristol, Pratik Naik, Sarah Mei, Sarah Allen, Wolfram Arnold, Alex Chaffee, Giles Bowkett, Evan Dorn, Long Nguyen, James Lindenbaum, Adam Wiggins, Tikhon Bernstam, Ron Evans, Wyatt Greene, Miles Forrest, the good people at Pivotal Labs, the Heroku gang, the thoughtbot guys, and the GitHub crew. Finally, many, many readers—far too many to list—have contributed a huge number of bug reports and suggestions during the writing of this book, and I gratefully acknowledge their help in making it as good as it can be.

Michael Hartl is the author of the Ruby on Rails Tutorial, the leading introduction to web development with Ruby on Rails. His prior experience includes writing and developing RailsSpace, an extremely obsolete Rails tutorial book, and developing Insoshi, a once-popular and now-obsolete social networking platform in Ruby on Rails. In 2011, Michael received a Ruby Hero Award for his contributions to the Ruby community. He is a graduate of Harvard College, has a Ph.D. in Physics from Caltech, and is an alumnus of the Y Combinator entrepreneur program.

Ruby on Rails Tutorial: Learn Web Development with Rails. Copyright © 2013 by Michael Hartl. All source code in the Ruby on Rails Tutorial is available jointly under the MIT License and the Beerware License.

The MIT License

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

/*
* ----------------------------------------------------------------------------
* "THE BEER-WARE LICENSE" (Revision 42):
* Michael Hartl wrote this code. As long as you retain this notice you
* can do whatever you want with this stuff. If we meet some day, and you think
* this stuff is worth it, you can buy me a beer in return.
* ----------------------------------------------------------------------------
*/


# Chapter 3 Mostly static pages

In this chapter, we will begin developing the sample application that will serve as our example throughout the rest of this tutorial. Although the sample app will eventually have users, microposts, and a full login and authentication framework, we will begin with a seemingly limited topic: the creation of static pages. Despite its apparent simplicity, making static pages is a highly instructive exercise, rich in implications—a perfect start for our nascent application.

Although Rails is designed for making database-backed dynamic websites, it also excels at making the kind of static pages we might make with raw HTML files. In fact, using Rails even for static pages yields a distinct advantage: we can easily add just a small amount of dynamic content. In this chapter we’ll learn how. Along the way, we’ll get our first taste of automated testing, which will help us be more confident that our code is correct. Moreover, having a good test suite will allow us to refactor our code with confidence, changing its form without changing its function.

There’s a lot of code in this chapter, especially in Section 3.2 and Section 3.3, and if you’re new to Ruby you shouldn’t worry about understanding the details right now. As noted in Section 1.1.1, one strategy is to copy-and-paste the tests and use them to verify the application code, without worrying at this point how they work. In addition, Chapter 4 covers Ruby in more depth, so there is plenty of opportunity for these ideas to sink in. Finally, RSpec tests will recur throughout the tutorial, so if you get stuck now I recommend forging ahead; you’ll be amazed how, after just a few more chapters, initially inscrutable code will suddenly look simple. (You might also consider the RSpec course at Code School, which one reader has said answered a lot of his RSpec questions.)

As in Chapter 2, before getting started we need to create a new Rails project, this time called sample_app:

$cd ~/rails_projects$ rails new sample_app --skip-test-unit
$cd sample_app  Here the --skip-test-unit option to the rails command tells Rails not to generate a test directory associated with the default Test::Unit framework. This is not because we won’t be writing tests; on the contrary, starting in Section 3.2 we will be using an alternate testing framework called RSpec to write a thorough test suite. As in Section 2.1, our next step is to use a text editor to update the Gemfile with the gems needed by our application. On the other hand, for the sample application we’ll also need two gems we didn’t need before: the gem for RSpec and the gem for the RSpec library specific to Rails. The code to include them is shown in Listing 3.1. (Note: If you would like to install all the gems needed for the sample application, you should use the code in Listing 9.47 at this time.) Listing 3.1. A Gemfile for the sample app. source 'https://rubygems.org' ruby '2.0.0' #ruby-gemset=railstutorial_rails_4_0 gem 'rails', '4.0.4' group :development, :test do gem 'sqlite3', '1.3.8' gem 'rspec-rails', '2.13.1' end group :test do gem 'selenium-webdriver', '2.35.1' gem 'capybara', '2.1.0' end gem 'sass-rails', '4.0.1' gem 'uglifier', '2.1.1' gem 'coffee-rails', '4.0.1' gem 'jquery-rails', '3.0.4' gem 'turbolinks', '1.1.1' gem 'jbuilder', '1.0.2' group :doc do gem 'sdoc', '0.3.20', require: false end group :production do gem 'pg', '0.15.1' gem 'rails_12factor', '0.0.2' end  This includes rspec-rails in a development environment so that we have access to RSpec-specific generators, and it includes it in test mode in order to run the tests. We don’t have to install RSpec itself because it is a dependency of rspec-rails and will thus be installed automatically. We also include the Capybara gem, which allows us to simulate a user’s interaction with the sample application using a natural English-like syntax, together with Selenium, one of Capybara’s dependencies.1 As in Chapter 2, we also must include the PostgreSQL and static assets gems in production for deployment to Heroku: group :production do gem 'pg', '0.15.1' gem 'rails_12factor', '0.0.2' end  Heroku recommends against using different databases in development and production, but for the sample application it won’t make any difference, and SQLite is much easier than PostgreSQL to install and configure. Installing and configuring PostgreSQL on your local machine is left as an exercise (Section 3.5). To install and include the new gems, we run bundle update and bundle install: $ bundle install --without production
$bundle update$ bundle install


As in Section 1.4.1 and Chapter 2, we suppress the installation of production gems using the option --without production. This is a “remembered option”, which means that we don’t have to include it in future invocations of Bundler. Instead, we can write simply bundle install and production gems will be ignored automatically.2

Because the sample application is shared as a public repository, it’s important to update the so-called secret token used by Rails to protect session variables so that it is dynamically generated rather than hard-coded (Listing 3.2). (The code in Listing 3.2 is fairly advanced for so early in the tutorial, but because it’s a potentially serious security issue I feel it’s important to include it even at this early stage.) Be sure to use the augmented .gitignore file from Listing 1.7 so that the .secret key isn’t exposed in your repository.

Listing 3.2. Dynamically generating a secret token.
config/initializers/secret_token.rb
# Be sure to restart your server when you modify this file.

# Your secret key is used for verifying the integrity of signed cookies.
# If you change this key, all old signed cookies will become invalid!

# Make sure the secret is at least 30 characters and all random,
# no regular words or you'll be exposed to dictionary attacks.
# You can use rake secret to generate a secure secret key.

# Make sure your secret_key_base is kept private
# if you're sharing your code publicly.
require 'securerandom'

def secure_token
token_file = Rails.root.join('.secret')
if File.exist?(token_file)
# Use the existing token.
else
# Generate a new token and store it in token_file.
token = SecureRandom.hex(64)
File.write(token_file, token)
token
end
end

SampleApp::Application.config.secret_key_base = secure_token


Next, we need to configure Rails to use RSpec in place of Test::Unit. This can be accomplished with rails generate rspec:install:

$rails generate rspec:install  If your system complains about the lack of a JavaScript runtime, visit the execjs page at GitHub for a list of possibilities. I particularly recommend installing Node.js. With that, all we have left is to initialize the Git repository:3 $ git init
$git add .$ git commit -m "Initial commit"


As with the first application, I suggest updating the README file (located in the root directory of the application) to be more helpful and descriptive, as shown in Listing 3.3.

Listing 3.3. An improved README file for the sample app.
# Ruby on Rails Tutorial: sample application

This is the sample application for
the [*Ruby on Rails Tutorial*](http://railstutorial.org/)
by [Michael Hartl](http://michaelhartl.com/).


Then change it to use the Markdown extension .md and commit the changes:

$git mv README.rdoc README.md$ git commit -am "Improve the README"


You may recall from Section 1.3.5 that we used the Git command git commit -a -m "Message", with flags for “all changes” (-a) and a message (-m). As shown in the second command above, Git also lets us roll the two flags into one using git commit -am "Message".

Since we’ll be using this sample app throughout the rest of the book, it’s a good idea to make a new repository at GitHub and push it up:

$git remote add origin https://github.com/<username>/sample_app.git$ git push -u origin master


As a result of my performing this step, you can find the Rails Tutorial sample application code on GitHub (under the username railstutorial and the slightly different name sample_app_rails_4).4

Of course, we can optionally deploy the app to Heroku even at this early stage:

$heroku create$ git push heroku master
$heroku run rake db:migrate  (As noted in Section 1.4.1, some readers have reported needing to precompile static assets (such as CSS and images), which can be included by hand as follows: # This should only be used if your Heroku deploy fails without it.$ rake assets:precompile
$git add .$ git commit -m "Add precompiled assets for Heroku"
$git push heroku master  This shouldn’t be necessary, and I have been unable to reproduce the issue, but the reports are common enough that I include it here for reference.) As you proceed through the rest of the book, I recommend pushing and deploying the application regularly: $ git push
$git push heroku$ heroku run rake db:migrate


This provides remote backups and lets you catch any production errors as soon as possible. If you run into problems at Heroku, make sure to take a look at the production logs to try to diagnose the problem:

$heroku logs  With all the preparation finished, we’re finally ready to get started developing the sample application. ## 3.1 Static pages In this section, we’ll take a first step toward making dynamic pages by creating a set of Rails actions and views containing (for now) only static HTML.5 Rails actions come bundled together inside controllers (the C in MVC from Section 1.2.6), which contain sets of actions related by a common purpose. We got a glimpse of controllers in Chapter 2, and will come to a deeper understanding once we explore the REST architecture more fully (starting in Chapter 6); in essence, a controller is a container for a group of (possibly dynamic) web pages. In order to get our bearings, it’s helpful to recall the Rails directory structure from Section 1.2.3 (Figure 1.2). In this section, we’ll be working mainly in the app/controllers and app/views directories. (In Section 3.2, we’ll even add a new directory of our own.) I suggest opening the sample app in your text editor or IDE at this time (Box 3.1). To get started with static pages, recall from Section 1.3.5 that, when using Git, it’s a good practice to do our work on a separate topic branch rather than the master branch. If you’re using Git for version control, you should run the following command: $ git checkout -b static-pages


Rails comes with a script for making controllers called generate; all it needs to work its magic is the controller’s name. Since we’ll be making a controller to handle static pages, we’ll call it the StaticPages controller. We’ll also plan to make actions for a Home page, a Help page, and an About page. The generate script takes an optional list of actions, so we’ll include two of the initial actions directly on the command line (Listing 3.4).

Listing 3.4. Generating a StaticPages controller.
$rails generate controller StaticPages home help --no-test-framework create app/controllers/static_pages_controller.rb route get "static_pages/help" route get "static_pages/home" invoke erb create app/views/static_pages create app/views/static_pages/home.html.erb create app/views/static_pages/help.html.erb invoke helper create app/helpers/static_pages_helper.rb invoke assets invoke coffee create app/assets/javascripts/static_pages.js.coffee invoke scss create app/assets/stylesheets/static_pages.css.scss  Here we’ve used the option --no-test-framework to suppress the generation of the default RSpec tests, which we won’t be using. Instead, we’ll create the tests by hand starting in Section 3.2. We’ve also intentionally left off the about action from the command line arguments in Listing 3.4 so that we can see how to add it using test-driven development, or TDD (Section 3.2). In Listing 3.4, note that we have passed the controller name as so-called CamelCase, which leads to the creation of a controller file written in snake case, so that a controller called StaticPages yields a file called static_pages_controller.rb. This is merely a convention, and in fact using snake case at the command line also works: the command $ rails generate controller static_pages ...


also generates a controller called static_pages_controller.rb. Because Ruby uses CamelCase for class names (Section 4.4), my preference is to refer to controllers using their CamelCase names, but this is a matter of taste. (Since Ruby filenames typically use snake case, the Rails generator converts CamelCase to snake case using the underscore method.)

By the way, if you ever make a mistake when generating code, it’s useful to know how to reverse the process. See Box 3.2 for some techniques on how to undo things in Rails.

The StaticPages controller generation in Listing 3.4 automatically updates the routes file, called config/routes.rb, which Rails uses to find the correspondence between URLs and web pages. This is our first encounter with the config directory, so it’s helpful to take a quick look at it (Figure 3.1). The config directory is where Rails collects files needed for the application configuration (hence the name).

Since we generated home and help actions, the routes file already has a rule for each one, as seen in Listing 3.5.

Listing 3.5. The routes for the home and help actions in the StaticPages controller.
config/routes.rb
SampleApp::Application.routes.draw do
get "static_pages/home"
get "static_pages/help"
.
.
.
end


Here the rule

get "static_pages/home"


maps requests for the URL /static_pages/home to the home action in the StaticPages controller. Moreover, by using get we arrange for the route to respond to a GET request, which is one of the fundamental HTTP verbs supported by the hypertext transfer protocol (Box 3.3). In our case, this means that when we generate a home action inside the StaticPages controller we automatically get a page at the address /static_pages/home. To see the results, navigate to /static_pages/home (Figure 3.2).

To understand where this page comes from, let’s start by taking a look at the StaticPages controller in a text editor; you should see something like Listing 3.6. You may note that, unlike the demo Users and Microposts controllers from Chapter 2, the StaticPages controller does not use the standard REST actions. This is normal for a collection of static pages—the REST architecture isn’t the best solution to every problem.

Listing 3.6. The StaticPages controller made by Listing 3.4.
app/controllers/static_pages_controller.rb
class StaticPagesController < ApplicationController

def home
end

def help
end
end


We see from the class keyword in Listing 3.6 that static_pages_controller.rb defines a class, in this case called StaticPagesController. Classes are simply a convenient way to organize functions (also called methods) like the home and help actions, which are defined using the def keyword. The angle bracket < indicates that StaticPagesController inherits from the Rails class ApplicationController; as we’ll see momentarily, this means that our pages come equipped with a large amount of Rails-specific functionality. (We’ll learn more about both classes and inheritance in Section 4.4.)

In the case of the StaticPages controller, both its methods are initially empty:

def home
end

def help
end


In plain Ruby, these methods would simply do nothing. In Rails, the situation is different—StaticPagesController is a Ruby class, but because it inherits from ApplicationController the behavior of its methods is specific to Rails: when visiting the URL /static_pages/home, Rails looks in the StaticPages controller and executes the code in the home action, and then renders the view (the V in MVC from Section 1.2.6) corresponding to the action. In the present case, the home action is empty, so all visiting /static_pages/home does is render the view. So, what does a view look like, and how do we find it?

If you take another look at the output in Listing 3.4, you might be able to guess the correspondence between actions and views: an action like home has a corresponding view called home.html.erb. We’ll learn in Section 3.3 what the .erb part means; from the .html part you probably won’t be surprised that it basically looks like HTML (Listing 3.7).

app/views/static_pages/home.html.erb
<h1>StaticPages#home</h1>
<p>Find me in app/views/static_pages/home.html.erb</p>


The view for the help action is analogous (Listing 3.8).

Listing 3.8. The generated view for the Help page.
app/views/static_pages/help.html.erb
<h1>StaticPages#help</h1>
<p>Find me in app/views/static_pages/help.html.erb</p>


Both of these views are just placeholders: they have a top-level heading (inside the h1 tag) and a paragraph (p tag) with the full path to the relevant file. We’ll add some (very slightly) dynamic content starting in Section 3.3, but as they stand these views underscore an important point: Rails views can simply contain static HTML.

In the remainder of this chapter, we’ll add some custom content to the Home and Help pages, and then add in the About page we left off in Section 3.1. Then we’ll add a very small amount of dynamic content by changing the title on a per-page basis.

Before moving on, if you’re using Git it’s a good idea to add the files for the StaticPages controller to the repository:

$git add .$ git commit -m "Add a StaticPages controller"


## 3.2 Our first tests

The Rails Tutorial takes an intuitive approach to testing that emphasizes the behavior of the application rather than its precise implementation, a variant of test-driven development (TDD) known as behavior-driven development (BDD). Our main tools will be integration tests (starting in this section) and unit tests (starting in Chapter 6). Integration tests, known as request specs in the context of RSpec, allow us to simulate the actions of a user interacting with our application using a web browser. Together with the natural-language syntax provided by Capybara, integration tests provide a powerful method to test our application’s functionality without having to manually check each page with a browser. (Another popular choice for BDD, called Cucumber, is introduced in Section 8.3.)

The defining quality of TDD is writing tests first, before the application code. Initially, this might take some getting used to, but the benefits are significant. By writing a failing test first and then implementing the application code to get it to pass, we increase our confidence that the test is actually covering the functionality we think it is. Moreover, the fail-implement-pass development cycle induces a flow state, leading to enjoyable coding and high productivity. Finally, the tests act as a client for the application code, often leading to more elegant software designs.

It’s important to understand that TDD is not always the right tool for the job: there’s no reason to dogmatically insist that tests always should be written first, that they should cover every single feature, or that there should necessarily be any tests at all. For example, when you aren’t at all sure how to solve a given programming problem, it’s often useful to skip the tests and write only application code, just to get a sense of what the solution will look like. (In the language of Extreme Programming (XP), this exploratory step is called a spike.) Once you see the general shape of the solution, you can then use TDD to implement a more polished version.

In this section, we’ll be running the tests using the rspec command supplied by the RSpec gem. This practice is straightforward but not ideal, and if you are a more advanced user I suggest setting up your system as described in Section 3.6.

### 3.2.1 Test-driven development

In test-driven development, we first write a failing test, represented in many testing tools by the color red. We then implement code to get the test to pass, represented by the color green. Finally, if necessary, we refactor the code, changing its form (by eliminating duplication, for example) without changing its function. This cycle is known as “Red, Green, Refactor”.

We’ll begin by adding some content to the Home page using test-driven development, including a top-level heading (<h1>) with the content Sample App. The first step is to generate an integration test (request spec) for our static pages:

$rails generate integration_test static_pages invoke rspec create spec/requests/static_pages_spec.rb  This creates the static_pages_spec.rb in the spec/requests directory. As with most generated code, the result is not pretty, so let’s open static_pages_spec.rb with a text editor and replace it with the contents of Listing 3.9. Listing 3.9. Code to test the contents of the Home page. spec/requests/static_pages_spec.rb require 'spec_helper' describe "Static pages" do describe "Home page" do it "should have the content 'Sample App'" do visit '/static_pages/home' expect(page).to have_content('Sample App') end end end  The code in Listing 3.9 is pure Ruby, but even if you’ve studied Ruby before it might not look familiar. This is because RSpec uses the general malleability of Ruby to define a domain-specific language (DSL) built just for testing. The important point is that you do not need to understand RSpec’s syntax to be able to use RSpec. It may seem like magic at first, but RSpec and Capybara are designed to read more or less like English, and if you follow the examples in this tutorial you’ll pick it up fairly quickly. Listing 3.9 contains a describe block with one example, i.e., a block starting with it "…" do: describe "Home page" do it "should have the content 'Sample App'" do visit '/static_pages/home' expect(page).to have_content('Sample App') end end  The first line indicates that we are describing the Home page. This description is just a string, and it can be anything you want; RSpec doesn’t care, but you and other human readers probably do. Then the spec says that when you visit the Home page at /static_pages/home, the content should contain the words “Sample App”. As with the first line, what goes inside the quote marks is irrelevant to RSpec, and is intended to be descriptive to human readers. Then the line visit '/static_pages/home'  uses the Capybara function visit to simulate visiting the URL /static_pages/home in a browser, while the line expect(page).to have_content('Sample App')  uses the page variable (also provided by Capybara) to express the expectation that the resulting page should have the right content. To get the test to run properly, we have to add a line to the spec_helper.rb file, as shown in Listing 3.10. (In the full third edition of the Rails Tutorial, I plan to eliminate this requirement by adopting the newer technique of feature specs.) Listing 3.10. Adding the Capybara DSL to the RSpec helper file. spec/spec_helper.rb # This file is copied to spec/ when you run 'rails generate rspec:install' . . . RSpec.configure do |config| . . . config.include Capybara::DSL end  To actually run the test, we have several options, including some convenient but rather advanced tools discussed in Section 3.6. For now, we’ll use the rspec command at the command line (executed with bundle exec to ensure that RSpec runs in the environment specified by our Gemfile):6 $ bundle exec rspec spec/requests/static_pages_spec.rb


This yields a failing test. The appearance of the result depends on your system; on my system, the red failing test appears as in Figure 3.3.7

To get the test to pass, we’ll replace the default Home page test with the HTML in Listing 3.11.

Listing 3.11. Code to get a passing test for the Home page.
app/views/static_pages/home.html.erb
<h1>Sample App</h1>
<p>
<a href="http://railstutorial.org/">Ruby on Rails Tutorial</a>
sample application.
</p>


This arranges for a top-level heading (<h1>) with the content Sample App, which should get the test to pass. We also include an anchor tag a, which creates links to the given URL (called an “href”, or “hypertext reference”, in the context of an anchor tag):

<a href="http://railstutorial.org/">Ruby on Rails Tutorial</a>


Now re-run the test to see the effect:

$bundle exec rspec spec/requests/static_pages_spec.rb  On my system, the passing test appears as in Figure 3.4. Based on the example for the Home page, you can probably guess the analogous test and application code for the Help page. We start by testing for the relevant content, in this case the string ’Help’ (Listing 3.12). Listing 3.12. Adding code to test the contents of the Help page. spec/requests/static_pages_spec.rb require 'spec_helper' describe "Static pages" do describe "Home page" do it "should have the content 'Sample App'" do visit '/static_pages/home' expect(page).to have_content('Sample App') end end describe "Help page" do it "should have the content 'Help'" do visit '/static_pages/help' expect(page).to have_content('Help') end end end  Then run the tests: $ bundle exec rspec spec/requests/static_pages_spec.rb


One test should fail. (Since systems will vary, and since keeping track of how many tests there are at each stage of the tutorial is a maintenance nightmare, I’ll omit the RSpec output from now on.)

The application code is similar to the code in Listing 3.11, as seen in Listing 3.13.

Listing 3.13. Code to get a passing test for the Help page.
app/views/static_pages/help.html.erb
<h1>Help</h1>
<p>
Get help on the Ruby on Rails Tutorial at the
<a href="http://railstutorial.org/help">Rails Tutorial help page</a>.
To get help on this sample app, see the
<a href="http://railstutorial.org/book">Rails Tutorial book</a>.
</p>


The tests should now pass:

$bundle exec rspec spec/requests/static_pages_spec.rb  ### 3.2.2 Adding a page Having seen test-driven development in action in a simple example, we’ll use the same technique to accomplish the slightly more complicated task of adding a new page, namely, the About page that we intentionally left off in Section 3.1. By writing a test and running RSpec at each step, we’ll see how TDD can guide us through the development of our application code. #### Red We’ll get to the Red part of the Red-Green cycle by writing a failing test for the About page. Following the models from Listing 3.12, you can probably guess the right test (Listing 3.14). Listing 3.14. Adding code to test the contents of the About page. spec/requests/static_pages_spec.rb require 'spec_helper' describe "Static pages" do describe "Home page" do it "should have the content 'Sample App'" do visit '/static_pages/home' expect(page).to have_content('Sample App') end end describe "Help page" do it "should have the content 'Help'" do visit '/static_pages/help' expect(page).to have_content('Help') end end describe "About page" do it "should have the content 'About Us'" do visit '/static_pages/about' expect(page).to have_content('About Us') end end end  #### Green Recall from Section 3.1 that we can generate a static page in Rails by creating an action and corresponding view with the page’s name. In our case, the About page will first need an action called about in the StaticPages controller. Having written a failing test, we can now be confident that, in getting it to pass, we will actually have created a working About page. If you run the RSpec example using $ bundle exec rspec spec/requests/static_pages_spec.rb


the output includes the following complaint:

No route matches [GET] "/static_pages/about"


This is a hint that we need to add /static_pages/about to the routes file, which we can accomplish by following the pattern in Listing 3.5, as shown in Listing 3.15.

Listing 3.15. Adding the about route.
config/routes.rb
SampleApp::Application.routes.draw do
get "static_pages/home"
get "static_pages/help"
.
.
.
end


Now running

$bundle exec rspec spec/requests/static_pages_spec.rb  complains that The action 'about' could not be found for StaticPagesController  To solve this problem, we follow the model provided by home and help from Listing 3.6 by adding an about action in the StaticPages controller (Listing 3.16). Listing 3.16. The StaticPages controller with added about action. app/controllers/static_pages_controller.rb class StaticPagesController < ApplicationController def home end def help end def about end end  Now running $ bundle exec rspec spec/requests/static_pages_spec.rb


says that we are missing a “template”, i.e., a view:

Missing template static_pages/about


To solve this issue, we add the about view. This involves creating a new file called about.html.erb in the app/views/static_pages directory with the contents shown in Listing 3.17.

Listing 3.17. Code for the About page.
app/views/static_pages/about.html.erb
<h1>About Us</h1>
<p>
The <a href="http://railstutorial.org/">Ruby on Rails Tutorial</a>
is a project to make a book and screencasts to teach web development
with <a href="http://rubyonrails.org/">Ruby on Rails</a>. This
is the sample application for the tutorial.
</p>


Running RSpec should now get us back to Green:

$bundle exec rspec spec/requests/static_pages_spec.rb  Of course, it’s never a bad idea to take a look at the page in a browser to make sure our tests aren’t completely crazy (Figure 3.5). #### Refactor Now that we’ve gotten to Green, we are free to refactor our code with confidence. Oftentimes code will start to “smell”, meaning that it gets ugly, bloated, or filled with repetition. The computer doesn’t care, of course, but humans do, so it is important to keep the code base clean by refactoring frequently. Having a good test suite is an invaluable tool in this regard, as it dramatically lowers the probability of introducing bugs while refactoring. Our sample app is a little too small to refactor right now, but code smell seeps in at every crack, and we won’t have to wait long: we’ll already get busy refactoring in Section 3.3.4. ## 3.3 Slightly dynamic pages Now that we’ve created the actions and views for some static pages, we’ll make them very slightly dynamic by adding some content that changes on a per-page basis: we’ll have the title of each page change to reflect its content. Whether a changing title represents truly dynamic content is debatable, but in any case it lays the necessary foundation for unambiguously dynamic content in Chapter 7. If you skipped the TDD material in Section 3.2, be sure to create an About page at this point using the code from Listing 3.15, Listing 3.16, and Listing 3.17. ### 3.3.1 Testing a title change Our plan is to edit the Home, Help, and About pages to make page titles that change on each page. This will involve using the <title> tag in our page views. Most browsers display the contents of the title tag at the top of the browser window (Google Chrome is an odd exception), and it is also important for search-engine optimization. We’ll start by writing tests for the titles, then add the titles themselves, and finally use a layout file to refactor the resulting pages and eliminate duplication. You may have noticed that the rails new command already created a layout file. We’ll learn its purpose shortly, but for now you should rename it before proceeding: $ mv app/views/layouts/application.html.erb foobar   # temporary change


(mv is a Unix command; on Windows you may need to rename the file using the file browser or the rename command.) You wouldn’t normally do this in a real application, but it’s easier to understand the purpose of the layout file if we start by disabling it.

PageURLBase titleVariable title
Home/static_pages/home"Ruby on Rails Tutorial Sample App""Home"
Help/static_pages/help"Ruby on Rails Tutorial Sample App""Help"
About/static_pages/about"Ruby on Rails Tutorial Sample App""About"
Table 3.1: The (mostly) static pages for the sample app.

By the end of this section, all three of our static pages will have titles of the form “Ruby on Rails Tutorial Sample App | Home”, where the last part of the title will vary depending on the page (Table 3.1). We’ll build on the tests in Listing 3.14, adding title tests following the model in Listing 3.18.

Listing 3.18. A title test.
it "should have the right title" do
visit '/static_pages/home'
expect(page).to have_title("Ruby on Rails Tutorial Sample App | Home")
end


This uses the have_title method, which checks for an HTML title with the given content. In other words, the code

expect(page).to have_title("Ruby on Rails Tutorial Sample App | Home")


checks to see that the content inside the title tag is

"Ruby on Rails Tutorial Sample App | Home"


It’s worth mentioning that the content need not be an exact match; any substring works as well, so that

expect(page).to have_title("Home")


will also match the full title.

Adding new tests for each of our three static pages, following the model of Listing 3.18, gives us our new StaticPages test (Listing 3.19). Note that there is considerable repetition here, which we will eliminate in Section 5.3.4.

Listing 3.19. The StaticPages controller spec with title tests.
spec/requests/static_pages_spec.rb
require 'spec_helper'

describe "Static pages" do

it "should have the content 'Sample App'" do
visit '/static_pages/home'
expect(page).to have_content('Sample App')
end

it "should have the title 'Home'" do
visit '/static_pages/home'
expect(page).to have_title("Ruby on Rails Tutorial Sample App | Home")
end
end

describe "Help page" do

it "should have the content 'Help'" do
visit '/static_pages/help'
expect(page).to have_content('Help')
end

it "should have the title 'Help'" do
visit '/static_pages/help'
expect(page).to have_title("Ruby on Rails Tutorial Sample App | Help")
end
end

it "should have the content 'About Us'" do
end

it "should have the title 'About Us'" do
expect(page).to have_title("Ruby on Rails Tutorial Sample App | About Us")
end
end
end


With the tests from Listing 3.19 in place, you should run

$bundle exec rspec spec/requests/static_pages_spec.rb  to verify that our code is now Red (failing tests). ### 3.3.2 Passing title tests Now we’ll get our title tests to pass, and at the same time add the full HTML structure needed to make valid web pages. The markup for a modern web page follows this form: <!DOCTYPE html> <html> <head> <title>Greeting</title> </head> <body> <p>Hello, world!</p> </body> </html>  This structure includes a document type, or doctype, declaration at the top to tell browsers which version of HTML we’re using (in this case, HTML5);8 a head section, in this case with “Greeting” inside a title tag; and a body section, in this case with “Hello, world!” inside a p (paragraph) tag. (The indentation is optional—HTML is not sensitive to whitespace, and ignores both tabs and spaces—but it makes the document’s structure easier to see.) Applying this basic structure to the Home page yields Listing 3.20. Listing 3.20. The view for the Home page with full HTML structure. app/views/static_pages/home.html.erb <!DOCTYPE html> <html> <head> <title>Ruby on Rails Tutorial Sample App | Home</title> </head> <body> <h1>Sample App</h1> <p> This is the home page for the <a href="http://railstutorial.org/">Ruby on Rails Tutorial</a> sample application. </p> </body> </html>  Listing 3.20 uses the title tested for in Listing 3.19: <title>Ruby on Rails Tutorial Sample App | Home</title>  As a result, the tests for the Home page should now pass. We’re still Red because of the failing Help and About tests, and we can get to Green with the code in Listing 3.21 and Listing 3.22. Listing 3.21. The view for the Help page with full HTML structure. app/views/static_pages/help.html.erb <!DOCTYPE html> <html> <head> <title>Ruby on Rails Tutorial Sample App | Help</title> </head> <body> <h1>Help</h1> <p> Get help on the Ruby on Rails Tutorial at the <a href="http://railstutorial.org/help">Rails Tutorial help page</a>. To get help on this sample app, see the <a href="http://railstutorial.org/book">Rails Tutorial book</a>. </p> </body> </html>  Listing 3.22. The view for the About page with full HTML structure. app/views/static_pages/about.html.erb <!DOCTYPE html> <html> <head> <title>Ruby on Rails Tutorial Sample App | About Us</title> </head> <body> <h1>About Us</h1> <p> The <a href="http://railstutorial.org/">Ruby on Rails Tutorial</a> is a project to make a book and screencasts to teach web development with <a href="http://rubyonrails.org/">Ruby on Rails</a>. This is the sample application for the tutorial. </p> </body> </html>  ### 3.3.3 Embedded Ruby We’ve achieved a lot already in this section, generating three valid pages using Rails controllers and actions, but they are purely static HTML and hence don’t show off the power of Rails. Moreover, they suffer from terrible duplication: • The page titles are almost (but not quite) exactly the same. • “Ruby on Rails Tutorial Sample App” is common to all three titles. • The entire HTML skeleton structure is repeated on each page. This repeated code is a violation of the important “Don’t Repeat Yourself” (DRY) principle; in this section and the next we’ll “DRY out our code” by removing the repetition. Paradoxically, we’ll take the first step toward eliminating duplication by first adding some more: we’ll make the titles of the pages, which are currently quite similar, match exactly. This will make it much simpler to remove all the repetition at a stroke. The technique involves using Embedded Ruby in our views. Since the Home, Help, and About page titles have a variable component, we’ll use a special Rails function called provide to set a different title on each page. We can see how this works by replacing the literal title “Home” in the home.html.erb view with the code in Listing 3.23. Listing 3.23. The view for the Home page with an Embedded Ruby title. app/views/static_pages/home.html.erb <% provide(:title, 'Home') %> <!DOCTYPE html> <html> <head> <title>Ruby on Rails Tutorial Sample App | <%= yield(:title) %></title> </head> <body> <h1>Sample App</h1> <p> This is the home page for the <a href="http://railstutorial.org/">Ruby on Rails Tutorial</a> sample application. </p> </body> </html>  Listing 3.23 is our first example of Embedded Ruby, also called ERb. (Now you know why HTML views have the file extension .html.erb.) ERb is the primary template system for including dynamic content in web pages.9 The code <% provide(:title, 'Home') %>  indicates using <% ... %> that Rails should call the provide function and associate the string ’Home’ with the label :title.10 Then, in the title, we use the closely related notation <%= ... %> to insert the title into the template using Ruby’s yield function:11 <title>Ruby on Rails Tutorial Sample App | <%= yield(:title) %></title>  (The distinction between the two types of embedded Ruby is that <% ... %> executes the code inside, while <%= ... %> executes it and inserts the result into the template.) The resulting page is exactly the same as before, only now the variable part of the title is generated dynamically by ERb. We can verify that all this works by running the tests from Section 3.3.1 and see that they still pass: $ bundle exec rspec spec/requests/static_pages_spec.rb


Then we can make the corresponding replacements for the Help and About pages (Listing 3.24 and Listing 3.25).

Listing 3.24. The view for the Help page with an Embedded Ruby title.
app/views/static_pages/help.html.erb
<% provide(:title, 'Help') %>
<!DOCTYPE html>
<html>
<title>Ruby on Rails Tutorial Sample App | <%= yield(:title) %></title>
<body>
<h1>Help</h1>
<p>
Get help on the Ruby on Rails Tutorial at the
<a href="http://railstutorial.org/help">Rails Tutorial help page</a>.
To get help on this sample app, see the
<a href="http://railstutorial.org/book">Rails Tutorial book</a>.
</p>
</body>
</html>

Listing 3.25. The view for the About page with an Embedded Ruby title.
app/views/static_pages/about.html.erb
<% provide(:title, 'About Us') %>
<!DOCTYPE html>
<html>
<title>Ruby on Rails Tutorial Sample App | <%= yield(:title) %></title>
<body>
<p>
The <a href="http://railstutorial.org/">Ruby on Rails Tutorial</a>
is a project to make a book and screencasts to teach web development
with <a href="http://rubyonrails.org/">Ruby on Rails</a>. This
is the sample application for the tutorial.
</p>
</body>
</html>


### 3.3.4 Eliminating duplication with layouts

Now that we’ve replaced the variable part of the page titles with ERb, each of our pages looks something like this:

<% provide(:title, 'Foo') %>
<!DOCTYPE html>
<html>
<title>Ruby on Rails Tutorial Sample App | <%= yield(:title) %></title>
<body>
Contents
</body>
</html>


In other words, all our pages are identical in structure, including the contents of the title tag, with the sole exception of the material inside the body tag.

In order to factor out this common structure, Rails comes with a special layout file called application.html.erb, which we renamed in Section 3.3.1 and which we’ll now restore:

$mv foobar app/views/layouts/application.html.erb  To get the layout to work, we have to replace the default title with the Embedded Ruby from the examples above: <title>Ruby on Rails Tutorial Sample App | <%= yield(:title) %></title>  The resulting layout appears in Listing 3.26. Listing 3.26. The sample application site layout. app/views/layouts/application.html.erb <!DOCTYPE html> <html> <head> <title>Ruby on Rails Tutorial Sample App | <%= yield(:title) %></title> <%= stylesheet_link_tag "application", media: "all", "data-turbolinks-track" => true %> <%= javascript_include_tag "application", "data-turbolinks-track" => true %> <%= csrf_meta_tags %> </head> <body> <%= yield %> </body> </html>  Note here the special line <%= yield %>  This code is responsible for inserting the contents of each page into the layout. It’s not important to know exactly how this works; what matters is that using this layout ensures that, for example, visiting the page /static_pages/home converts the contents of home.html.erb to HTML and then inserts it in place of <%= yield %>. It’s also worth noting that the default Rails layout includes several additional lines: <%= stylesheet_link_tag ... %> <%= javascript_include_tag "application", ... %> <%= csrf_meta_tags %>  This code arranges to include the application stylesheet and JavaScript, which are part of the asset pipeline (Section 5.2.1), together with the Rails method csrf_meta_tags, which prevents cross-site request forgery (CSRF), a type of malicious web attack. Of course, the views in Listing 3.23, Listing 3.24, and Listing 3.25 are still filled with all the HTML structure included in the layout, so we have to remove it, leaving only the interior contents. The resulting cleaned-up views appear in Listing 3.27, Listing 3.28, and Listing 3.29. Listing 3.27. The Home page with HTML structure removed. app/views/static_pages/home.html.erb <% provide(:title, 'Home') %> <h1>Sample App</h1> <p> This is the home page for the <a href="http://railstutorial.org/">Ruby on Rails Tutorial</a> sample application. </p>  Listing 3.28. The Help page with HTML structure removed. app/views/static_pages/help.html.erb <% provide(:title, 'Help') %> <h1>Help</h1> <p> Get help on the Ruby on Rails Tutorial at the <a href="http://railstutorial.org/help">Rails Tutorial help page</a>. To get help on this sample app, see the <a href="http://railstutorial.org/book">Rails Tutorial book</a>. </p>  Listing 3.29. The About page with HTML structure removed. app/views/static_pages/about.html.erb <% provide(:title, 'About Us') %> <h1>About Us</h1> <p> The <a href="http://railstutorial.org/">Ruby on Rails Tutorial</a> is a project to make a book and screencasts to teach web development with <a href="http://rubyonrails.org/">Ruby on Rails</a>. This is the sample application for the tutorial. </p>  With these views defined, the Home, Help, and About pages are the same as before, but they have much less duplication. Verifying that the test suite still passes gives us confidence that this code refactoring was successful: $ bundle exec rspec spec/requests/static_pages_spec.rb


## 3.4 Conclusion

Seen from the outside, this chapter hardly accomplished anything: we started with static pages, and ended with… mostly static pages. But appearances are deceiving: by developing in terms of Rails controllers, actions, and views, we are now in a position to add arbitrary amounts of dynamic content to our site. Seeing exactly how this plays out is the task for the rest of this tutorial.

Before moving on, let’s take a minute to commit our changes and merge them into the master branch. Back in Section 3.1 we created a Git branch for the development of static pages. If you haven’t been making commits as we’ve been moving along, first make a commit indicating that we’ve reached a stopping point:

$git add .$ git commit -m "Finish static pages"


Then merge the changes back into the master branch using the same technique as in Section 1.3.5:

$git checkout master$ git merge static-pages


Once you reach a stopping point like this, it’s usually a good idea to push your code up to a remote repository (which, if you followed the steps in Section 1.3.4, will be GitHub):

$git push  If you like, at this point you can even deploy the updated application to Heroku: $ git push heroku


## 3.5 Exercises

1. Make a Contact page for the sample app. Following the model in Listing 3.19, first write a test for the existence of a page at the URL /static_pages/contact by testing for the title “Ruby on Rails Tutorial Sample App | Contact”. Get your test to pass by filling the Contact page with the content from Listing 3.30. (This exercise is solved as part of Section 5.3.)
2. You may have noticed some repetition in the StaticPages controller spec (Listing 3.19). In particular, the base title, “Ruby on Rails Tutorial Sample App”, is the same for every title test. Using the RSpec let function, which creates a variable corresponding to its argument, verify that the tests in Listing 3.31 still pass. Listing 3.31 introduces string interpolation, which is covered further in Section 4.2.2.
3. (advanced) As noted on the Heroku page on using sqlite3 for development, it’s a good idea to use the same database in development, test, and production environments to minimize the possibility of subtle incompatibilities. Follow the Heroku instructions for local PostgreSQL installation to install the PostgreSQL database on your local system. Update your Gemfile to eliminate the sqlite3 gem and use the pg gem exclusively, as shown in Listing 3.32. You will also have to learn about the config/database.yml file and how to run PostgreSQL locally. (Note that for security you should add database.yml to your .gitignore file, as shown in Listing 1.7.) Your goal should be to create and configure both the development database and the test database to use PostgreSQL. I especially recommend using Induction to connect to and view the local PostgreSQL database. Warning: You may find this exercise challenging, and I recommend it only for advanced users. If you get stuck, don’t hesitate to skip it; as noted previously, the sample application developed in this tutorial is fully compatible with both SQLite and PostgreSQL.
Listing 3.30. Code for a proposed Contact page.
app/views/static_pages/contact.html.erb
<% provide(:title, 'Contact') %>
<h1>Contact</h1>
<p>
Contact Ruby on Rails Tutorial about the sample app at the
<a href="http://railstutorial.org/contact">contact page</a>.
</p>

Listing 3.31. The StaticPages controller spec with a base title.
spec/requests/static_pages_spec.rb
require 'spec_helper'

describe "Static pages" do

let(:base_title) { "Ruby on Rails Tutorial Sample App" }

it "should have the content 'Sample App'" do
visit '/static_pages/home'
expect(page).to have_content('Sample App')
end

it "should have the title 'Home'" do
visit '/static_pages/home'
expect(page).to have_title("#{base_title} | Home")
end
end

describe "Help page" do

it "should have the content 'Help'" do
visit '/static_pages/help'
expect(page).to have_content('Help')
end

it "should have the title 'Help'" do
visit '/static_pages/help'
expect(page).to have_title("#{base_title} | Help")
end
end

it "should have the content 'About Us'" do
end

it "should have the title 'About Us'" do
end
end

describe "Contact page" do

it "should have the content 'Contact'" do
visit '/static_pages/contact'
expect(page).to have_content('Contact')
end

it "should have the title 'Contact'" do
visit '/static_pages/contact'
expect(page).to have_title("#{base_title} | Contact")
end
end
end

Listing 3.32. The Gemfile needed to use PostgreSQL instead of SQLite.
source 'https://rubygems.org'
ruby '2.0.0'
#ruby-gemset=railstutorial_rails_4_0

gem 'rails', '4.0.4'
gem 'pg', '0.15.1'

group :development, :test do
gem 'rspec-rails', '2.13.1'
end

group :test do
gem 'selenium-webdriver', '2.35.1'
gem 'capybara', '2.1.0'
end

gem 'sass-rails', '4.0.1'
gem 'uglifier', '2.1.1'
gem 'coffee-rails', '4.0.1'
gem 'jquery-rails', '3.0.4'
gem 'jbuilder', '1.0.2'

group :doc do
gem 'sdoc', '0.3.20', require: false
end

group :production do
gem 'rails_12factor', '0.0.2'
end


As mentioned briefly in Section 3.2, using the rspec command directly is not ideal. In this section, we’ll first discuss a method to eliminate the necessity of typing bundle exec, and then set up testing to automate the running of the test suite using Guard (Section 3.6.2) and, optionally, Spork (Section 3.6.3). Finally, we’ll mention a method for running tests directly inside Sublime Text, a technique especially useful when used in concert with Spork.

This section should only be attempted by fairly advanced users and can be skipped without loss of continuity. Among other things, this material is likely to go out of date faster than the rest of the tutorial, so you shouldn’t expect everything on your system to match the examples exactly, and you may have to Google around to get everything to work.

### 3.6.1 Eliminating bundle exec

As mentioned briefly in Section 3.2.1, it is necessary in general to prefix commands such as rake or rspec with bundle exec so that the programs run in the exact gem environment specified by the Gemfile. (For technical reasons, the only exception to this is the rails command itself.) This practice is rather cumbersome, and in this section we discuss two ways to eliminate its necessity.

#### RVM Bundler integration

The first and preferred method is to use RVM, which includes Bundler integration as of version 1.11. You can verify that you have a sufficiently up-to-date version of RVM as follows:

$rvm get stable$ rvm -v

rvm 1.19.5 (stable)


As long as the version number is 1.11.x or greater, installed gems will automatically be executed in the proper Bundler environment, so that you can write (for example)

$rspec spec/  and omit the leading bundle exec. If this is the case, you should skip the rest of this section. If for any reason you are restricted to an earlier version of RVM, you can still eliminate bundle exec by using RVM Bundler integration12 to configure the Ruby Version Manager to include the proper executables automatically in the local environment. The steps are simple if somewhat mysterious. First, run these two commands: $ rvm get head && rvm reload
$chmod +x$rvm_path/hooks/after_cd_bundler


Then run these:

$cd ~/rails_projects/sample_app$ bundle install --without production --binstubs=./bundler_stubs


Together, these commands combine RVM and Bundler magic to ensure that commands such as rake and rspec are automatically executed in the right environment. Since these files are specific to your local setup, you should add the bundler_stubs directory to your .gitignore file (Listing 3.33).

Listing 3.33. Adding bundler_stubs to the .gitignore file.
# Ignore bundler config.
/.bundle

# Ignore the default SQLite database.
/db/*.sqlite3
/db/*.sqlite3-journal

# Ignore all logfiles and tempfiles.
/log/*.log
/tmp

# Ignore other unneeded files.
doc/
*.swp
*~
.project
.DS_Store
.idea
bundler_stubs/


If you add another executable (such as guard in Section 3.6.2), you should re-run the bundle install command:

$bundle install --binstubs=./bundler_stubs  #### binstubs If you’re not using RVM, you can still avoid typing bundle exec using the rubygems-bundler gem: $ gem install rubygems-bundler
$gem regenerate_binstubs  The second command creates all the necessary executables locally, so that we can now run the test suite as follows: $ rspec spec/


The same goes for rake, etc.:

$rake db:migrate  If you add another executable (such as guard in Section 3.6.2), you might have to re-run gem regenerate_binstubs. (This shouldn’t be necessary, but I mention the possibility just in case.) For the sake of readers who skip this section, the rest of this tutorial will err on the side of caution and explicitly use bundle exec, but of course you should feel free to use the more compact version if your system is properly configured. ### 3.6.2 Automated tests with Guard One annoyance associated with using the rspec command is having to switch to the command line and run the tests by hand. (A second annoyance, the slow start-up time of the test suite, is addressed in Section 3.6.3.) In this section, we’ll show how to use Guard to automate the running of the tests. Guard monitors changes in the filesystem so that, for example, when we change the static_pages_spec.rb file only those tests get run. Even better, we can configure Guard so that when, say, the home.html.erb file is modified, the static_pages_spec.rb automatically runs. First we add guard-rspec to the Gemfile (Listing 3.34). Listing 3.34. A Gemfile for the sample app, including Guard. source 'https://rubygems.org' ruby '2.0.0' #ruby-gemset=railstutorial_rails_4_0 gem 'rails', '4.0.4' group :development, :test do gem 'sqlite3', '1.3.8' gem 'rspec-rails', '2.13.1' gem 'guard-rspec', '2.5.0' end group :test do gem 'selenium-webdriver', '2.35.1' gem 'capybara', '2.1.0' # Uncomment this line on OS X. # gem 'growl', '1.0.3' # Uncomment these lines on Linux. # gem 'libnotify', '0.8.0' # Uncomment these lines on Windows. # gem 'rb-notifu', '0.0.4' # gem 'win32console', '1.3.2' # gem 'wdm', '0.1.0' end gem 'sass-rails', '4.0.1' gem 'uglifier', '2.1.1' gem 'coffee-rails', '4.0.1' gem 'jquery-rails', '3.0.4' gem 'turbolinks', '1.1.1' gem 'jbuilder', '1.0.2' group :doc do gem 'sdoc', '0.3.20', require: false end group :production do gem 'pg', '0.15.1' gem 'rails_12factor', '0.0.2' end  Be sure to uncomment the lines in the test group relevant for your system. (Note that, if you want Growl notifications, you will have to purchase Growl, which is available in the Apple App Store for a nominal charge.) We next install the gems by running bundle install: $ bundle install


Then initialize Guard so that it works with RSpec:

$bundle exec guard init rspec Writing new Guardfile to /Users/mhartl/rails_projects/sample_app/Guardfile rspec guard added to Guardfile, feel free to edit it  Now edit the resulting Guardfile so that Guard will run the right tests when the integration tests and views are updated (Listing 3.35). Listing 3.35. Additions to the default Guardfile. Note the added require. require 'active_support/inflector' guard 'rspec', all_after_pass: false do . . . watch('config/routes.rb') # Custom Rails Tutorial specs watch(%r{^app/controllers/(.+)_(controller)\.rb$}) do |m|
["spec/routing/#{m[1]}_routing_spec.rb",
"spec/#{m[2]}s/#{m[1]}_#{m[2]}_spec.rb",
"spec/acceptance/#{m[1]}_spec.rb",
(m[1][/_pages/] ? "spec/requests/#{m[1]}_spec.rb" :
"spec/requests/#{m[1].singularize}_pages_spec.rb")]
end
watch(%r{^app/views/(.+)/}) do |m|
(m[1][/_pages/] ? "spec/requests/#{m[1]}_spec.rb" :
"spec/requests/#{m[1].singularize}_pages_spec.rb")
end
watch(%r{^app/controllers/sessions_controller\.rb$}) do |m| "spec/requests/authentication_pages_spec.rb" end . . . end  Here the line guard 'rspec', all_after_pass: false do  ensures that Guard doesn’t run all the tests after a failing test passes (to speed up the Red-Green-Refactor cycle). We can now start guard as follows: $ bundle exec guard


To eliminate the need to prefix the command with bundle exec, re-follow the steps in Section 3.6.1.

By the way, if you get a Guard error complaining about the absence of a spec/routing directory, you can fix it by creating an empty one:

$mkdir spec/routing  ### 3.6.3 Speeding up tests with Spork When running bundle exec rspec, you may have noticed that it takes several seconds just to start running the tests, but once they start running they finish quickly. This is because each time RSpec runs the tests it has to reload the entire Rails environment. The Spork test server13 aims to solve this problem. Spork loads the environment once, and then maintains a pool of processes for running future tests. Spork is particularly useful when combined with Guard (Section 3.6.2). The first step is to add the spork gem dependency to the Gemfile (Listing 3.36). Listing 3.36. A Gemfile for the sample app, including Spork. source 'https://rubygems.org' ruby '2.0.0' #ruby-gemset=railstutorial_rails_4_0 gem 'rails', '4.0.4' group :development, :test do . . . gem 'spork-rails', '4.0.0' gem 'guard-spork', '1.5.0' gem 'childprocess', '0.3.6' end . . .  Then install Spork using bundle install: $ bundle install


Next, bootstrap the Spork configuration:

$bundle exec spork --bootstrap  Now we need to edit the RSpec configuration file, located in spec/spec_helper.rb, so that the environment gets loaded in a prefork block, which arranges for it to be loaded only once (Listing 3.37). Listing 3.37. Adding environment loading to the Spork.prefork block. spec/spec_helper.rb require 'rubygems' require 'spork' Spork.prefork do ENV["RAILS_ENV"] ||= 'test' require File.expand_path("../../config/environment", __FILE__) require 'rspec/rails' require 'rspec/autorun' # Requires supporting ruby files with custom matchers and macros, etc, # in spec/support/ and its subdirectories. Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f} # Checks for pending migrations before tests are run. # If you are not using ActiveRecord, you can remove this line. ActiveRecord::Migration.check_pending! if defined?(ActiveRecord::Migration) RSpec.configure do |config| # ## Mock Framework # # If you prefer to use mocha, flexmock or RR, uncomment the appropriate line: # # config.mock_with :mocha # config.mock_with :flexmock # config.mock_with :rr # Remove this line if you're not using ActiveRecord or ActiveRecord fixtures config.fixture_path = "#{::Rails.root}/spec/fixtures" # If you're not using ActiveRecord, or you'd prefer not to run each of your # examples within a transaction, remove the following line or assign false # instead of true. config.use_transactional_fixtures = true # If true, the base class of anonymous controllers will be inferred # automatically. This will be the default behavior in future versions of # rspec-rails. config.infer_base_class_for_anonymous_controllers = false # Run specs in random order to surface order dependencies. If you find an # order dependency and want to debug it, you can fix the order by providing # the seed, which is printed after each run. # --seed 1234 config.order = "random" config.include Capybara::DSL end end Spork.each_run do # This code will be run each time you run your specs. end  Before running Spork, we can get a baseline for the testing overhead by timing our test suite as follows: $ time bundle exec rspec spec/requests/static_pages_spec.rb
......

6 examples, 0 failures

real	0m8.633s
user	0m7.240s
sys	0m1.068s


Here the test suite takes more than seven seconds to run even though the actual tests run in under a tenth of a second. To speed this up, we can open a dedicated terminal window, navigate to the application root directory, and then start a Spork server:

$bundle exec spork Using RSpec Loading Spork.prefork block... Spork is ready and listening on 8989!  (To eliminate the need to prefix the command with bundle exec, re-follow the steps in Section 3.6.1.) In another terminal window, we can now run our test suite with the --drb (“distributed Ruby”) option and verify that the environment-loading overhead is greatly reduced: $ time bundle exec rspec spec/requests/static_pages_spec.rb --drb
......

6 examples, 0 failures

real	0m2.649s
user	0m1.259s
sys	0m0.258s


It’s inconvenient to have to include the --drb option every time we run rspec, so I recommend adding it to the .rspec file in the application’s root directory, as shown in Listing 3.38.

Listing 3.38. Configuring RSpec to automatically use Spork.
.rspec
--colour
--drb


One word of advice when using Spork: after changing a file included in the prefork loading (such as routes.rb), you will have to restart the Spork server to load the new Rails environment. If your tests are failing when you think they should be passing, quit the Spork server with Ctrl-C and restart it:

$bundle exec spork Using RSpec Loading Spork.prefork block... Spork is ready and listening on 8989! ^C$ bundle exec spork


#### Guard with Spork

Spork is especially useful when used with Guard, which we can arrange as follows:

$bundle exec guard init spork  We then need to change the Guardfile as in Listing 3.39. Listing 3.39. The Guardfile updated for Spork. require 'active_support/inflector' guard 'spork', :cucumber_env => { 'RAILS_ENV' => 'test' }, :rspec_env => { 'RAILS_ENV' => 'test' } do watch('config/application.rb') watch('config/environment.rb') watch('config/environments/test.rb') watch(%r{^config/initializers/.+\.rb$})
watch('Gemfile')
watch('Gemfile.lock')
watch('spec/spec_helper.rb') { :rspec }
watch('test/test_helper.rb') { :test_unit }
watch(%r{features/support/}) { :cucumber }
end

guard 'rspec', all_after_pass: false, cli: '--drb' do
.
.
.
end


Note that we’ve updated the arguments to guard to include cli: '--drb', which ensures that Guard uses the command-line interface (cli) to the Spork server. We’ve also added a command to watch the features/support/ directory, which we’ll start modifying in Chapter 5.

With that configuration in place, we can start Guard and Spork at the same time with the guard command:

$bundle exec guard  Guard automatically starts a Spork server, dramatically reducing the overhead each time a test gets run. A well-configured testing environment with Guard, Spork, and (optionally) test notifications makes test-driven development positively addictive. See the Rails Tutorial screencasts14 for more information. ### 3.6.4 Tests inside Sublime Text If you’re using Sublime Text, there is a powerful set of helper commands to run tests directly inside the editor. This is currently my preferred setup, as it works great when you only have a few tests while still scaling nicely even to very large (and therefore long-running) test suites. To get them working, follow the instructions for your platform at Sublime Text 2 Ruby Tests.15 On my platform (Macintosh OS X), I can install the commands as follows: $ cd ~/Library/Application\ Support/Sublime\ Text\ 2/Packages
\$ git clone https://github.com/maltize/sublime-text-2-ruby-tests.git RubyTest


You may also want to follow the setup instructions for Rails Tutorial Sublime Text at this time.16

After restarting Sublime Text, the RubyTest package supplies the following commands:

• Command-Shift-R: run a single test (if run on an it block) or group of tests (if run on a describe block)
• Command-Shift-E: run the last test(s)
• Command-Shift-T: run all the tests in current file

Because test suites can become quite slow even for relatively small projects, being able to run one test (or a small group of tests) at a time can be a huge win. Even a single test requires the same Rails environment overhead, of course, which is why these commands are perfectly complemented by Spork: running a single test eliminates the overhead of running the entire test file, while running Spork eliminates the overhead of starting the test environment. Here is the sequence I recommend:

1. Start Spork in a terminal window.
2. Write a single test or small group of tests.
3. Run Command-Shift-R to verify that the test or test group is red.
4. Write the corresponding application code.
5. Run Command-Shift-E to run the same test/group again, verifying that it’s green.
6. Repeat steps 2–5 as necessary.
7. When reaching a natural stopping point (such as before a commit), run rspec spec/ at the command line to confirm that the entire test suite is still green.

Even with the ability to run tests inside of Sublime Text, I still sometimes prefer using Guard, but at this point my bread-and-butter TDD technique is the one enumerated above.

1. The successor to Webrat, Capybara is named after the world’s largest rodent
2. In fact, you can even leave off install. The bundle command by itself is an alias for bundle install
3. As before, you may find the augmented file from Listing 1.7 to be more convenient depending on your system.
4. https://github.com/railstutorial/sample_app_rails_4
5. Our method for making static pages is probably the simplest, but it’s not the only way. The optimal method really depends on your needs; if you expect a large number of static pages, using a StaticPages controller can get quite cumbersome, but in our sample app we’ll only need a few.
6. Running bundle exec every time is rather cumbersome; see Section 3.6 for some options to eliminate it.
7. I actually use a dark background for both my terminal and editor, but the light background looks better in the screenshots.
8. HTML changes with time; by explicitly making a doctype declaration we make it likelier that browsers will render our pages properly in the future. The extremely simple doctype <!DOCTYPE html> is characteristic of the latest HTML standard, HTML5.
9. There is a second popular template system called Haml, which I personally love, but it’s not quite standard enough yet for use in an introductory tutorial.
10. Experienced Rails developers might have expected the use of content_for at this point, but it doesn’t work well with the asset pipeline. The provide function is its replacement.
11. If you’ve studied Ruby before, you might suspect that Rails is yielding the contents to a block, and your suspicion would be correct. But you don’t need to know this to develop applications with Rails.
12. http://rvm.io/integration/bundler/
13. A spork is a combination spoon-fork. The project’s name is a pun on Spork’s use of POSIX forks
14. http://railstutorial.org/screencasts
15. https://github.com/maltize/sublime-text-2-ruby-tests
16. https://github.com/mhartl/rails_tutorial_sublime_text
Michael Hartl is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.