3.2.1 静的なページの生成

静的なページの作成は、第2章でscaffold生成に使用したgenerateスクリプトで、コントローラを生成することから始めます。このコントローラは静的なページを扱うためにしか使わないので、コントローラ名を「Static Pages」に決め、表記をキャメルケースのStaticPagesにします。続いて、Homeページ、Helpページ、Aboutページに使用するアクションもそれぞれ作成することにし、アクション名はすべて小文字のhome、help、aboutにします。generateスクリプトではアクション名をまとめて指定することもできるので、コマンドラインでHomeページとHelpページ用のアクションもまとめて生成することにします。なお、Aboutページだけは学習のため、あえてコマンドラインでは作成せず、3.3で手動で追加することにします。これらの要素を盛り込んだStaticPagesコントローラ生成コマンドと実行結果をリスト3.4に示します。

$ rails generate controller StaticPages home help
      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  test_unit
      create    test/controllers/static_pages_controller_test.rb
      invoke  helper
      create    app/helpers/static_pages_helper.rb
      invoke    test_unit
      create      test/helpers/static_pages_helper_test.rb
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/static_pages.js.coffee
      invoke    scss
      create      app/assets/stylesheets/static_pages.css.scss

追伸: rails gは rails generateコマンドの短縮形であり、Railsでサポートされている多数の短縮形のひとつです (表3.1)。本チュートリアルではわかりやすさを重んじているため、こうしたコマンドは短縮せずに表記していますが、現実のRails開発者はほぼ間違いなく表3.1の短縮形を常用しています。

次に進む前に、StaticPagesコントローラファイルをGitリポジトリに追加しておきましょう。

$ git status
$ git add -A
$ git commit -m "Add a Static Pages controller"
$ git push -u origin static-pages

最後のコマンドでは、static-pagesトピックブランチをBitbucketにプッシュしています。以後は、単に以下を実行するだけで同じプッシュが行われるようになります。

$ git push

上のコミット〜プッシュの流れは、著者が実際の開発でよく使っていたパターンに基づいていますが、ここから先は途中でこのような指示をいちいち書くことはしませんので、各自こまめにプッシュするようにしてください。

リスト3.4では、コントローラ名をキャメルケース (訳注: 単語の頭文字を大文字にしてつなぎ合わせた名前) で渡していることに注目してください。こうすると、StaticPagesコントローラ名をスネークケース (訳注: 単語間にアンダースコアを加えて繋ぎ合わせた名前) にしたファイル static_pages_controller.rb を自動的に生成します。ただし、上のような命名は単なる慣習に過ぎません。実際、コマンドライン上で以下のようなスネークケースのコントローラ名を入力しても、

$ rails generate controller static_pages ...

先ほどと同様にstatic_pages_controller.rbというコントローラが生成されます。これは、Rubyがクラス名にキャメルケースを使う慣習があり (詳細は4.4で説明します)、また、キャメルケースの名前を使うことが好まれているためです。これらの慣習に必ず従わなければいけないということではありません。(同様にRubyでは、ファイル名をスネークケースで記述する慣習があります。このため Railsのgenerateスクリプトでは、 underscoreメソッドを使ってキャメルケースをスネークケースに変換しています。)

ところで、自動生成に失敗するようなことがあれば、元に戻す処理を学ぶ良い機会になります。以下のコラム3.1で元に戻す方法を紹介しています。

  $ rails generate controller StaticPages home help
  $ rails destroy  controller StaticPages home help

  $ rails generate model User name:string email:string

  $ rails destroy model User

  $ bundle exec rake db:migrate

  $ bundle exec rake db:rollback

  $ bundle exec rake db:migrate VERSION=0

リスト3.4のようにStaticPagesコントローラを生成すると、(config/routes.rb)ファイルが自動的に更新されます (1.3.4のときと同様です)。このルーティングファイルはルーターの実装を受け持ち (図2.11)、URLとWebページの対応関係を定義します。このルーティングファイルはRailsのconfigディレクトリの下に置かれます。このディレクトリには、Railsの設定ファイルがまとめて置かれます (図3.1)。

図3.1 サンプルアプリケーションのconfigディレクトリの内容

先ほどリスト3.4のようにhomeアクションとhelpアクションを生成したので、routesファイルにはそれぞれのアクションで使用されるルールが定義されています (リスト3.5)。

Rails.application.routes.draw do
  get 'static_pages/home'
  get 'static_pages/help'
  .
  .
  .
end

ここで以下のルールに注目してみましょう。

get 'static_pages/home'

このルールは、/static_pages/homeというURLに対するリクエストを、StaticPagesコントローラのhomeアクションと結びつけています。具体的には、getと書くことで、GETリクエストに対して該当するアクションを結びつけています。なお、ここでいう GETリクエストとは、HTTP (HyperText Transfer Protocol) (コラム3.2) が対応しているメソッドの1つです。今回の場合は、StaticPagesコントローラ内にhomeアクションを追加したので、/static_pages/homeにアクセスすることでページを取得 (GET) できるようになりました。結果を確認するには、1.3.2に従って以下のようにRailsのdevelopmentサーバーを起動します。

$ rails server -b $IP -p $PORT    # ローカルサーバーの場合は`rails server`だけを実行する

/static_pages/homeにアクセスして結果を表示します (図3.2)。

図3.2 /static_pages/homeにアクセスした結果

このページがどのようにして表示されるのかを理解するために、まずはテキストエディタでStaticPagesコントローラを開いてみましょう。リスト3.6のような内容になっているはずです。ここで、第2章のUsersコントローラやMicropostsコントローラとは異なり、StaticPagesコントローラは一般的なRESTアクションに対応していないことに注意してください。これは、静的なページの集合に対しては、適切なアクションと言えます。言い換えると、RESTアーキテクチャは、あらゆる問題に対して最適な解決方法であるとは限らないということです。

class StaticPagesController < ApplicationController

  def home
  end

  def help
  end
end

リスト 3.6のclassというキーワードから、static_pages_controller.rbはStaticPagesControllerというクラスを定義していることがわかります。クラスは、関数 (メソッドとも呼ばれます) をまとめるときに便利な手法です。今回の例では、defというキーワードを使って、homeアクションやhelpアクションを定義しています。2.3.4で説明したように、山括弧<は、StaticPagesControllerがApplicationControllerというRailsのクラスを継承していることを示しています。この後も説明しますが、今回作成したページには、Rails特有の機能が多数使用されています (具体的なクラスや継承については、4.4で詳しく説明します)。

今回のStaticPagesコントローラにあるメソッドは、以下のようにどちらも最初は空になっています。

def home
end

def help
end

純粋なRuby言語であれば、これらのメソッドは何も実行しません。しかし、Railsでは動作が異なります。StaticPagesControllerはRuby のクラスですが、ApplicationControllerクラスを継承しているため、StaticPagesControllerのメソッドは (たとえ何も書かれていなくても) Rails特有の振る舞いをします。具体的には、/static_pages/homeというURLにアクセスすると、RailsはStaticPagesコントローラを参照し、homeアクションに記述されているコードを実行します。その後、そのアクションに対応するビュー (1.3.3で説明したMVCのVに相当) を出力します。今回の場合、homeアクションが空になっているので、/static_pages/homeにアクセスしても、単に対応するビューが出力されるだけです。では、ビューはどのように出力されるのでしょうか。また、どのビューが表示されるのでしょうか。

リスト3.4をもう一度注意深く読んでみると、アクションとビューの関係性について理解できるでしょう。homeアクションは、home.html.erbというビューに対応しています。.erbの詳細については3.4で説明しますが、ファイル名に.htmlが含まれていることからわかるように、基本的にはHTMLと同じような構造になっています (リスト3.7)。

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

helpアクションに対応するビューも、上のコードと似ています (リスト3.8)。

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

どちらのビューも単なるプレースホルダになっています。トップレベルの見出しがh1タグの中にあり、関連するファイルへの絶対パスがpタグの中に書かれています。

3.2.2 静的なページの調整

3.4からは (ほんの少しだけ) 動的なコンテンツを追加しますが、リスト3.7やリスト3.8で見たように、重要なのは「Railsのビューの中には静的なHTMLがある」という点です。これは、Railsの知識が無くてもHomeページやHelpページを修正できることを意味しています。以下のリスト3.9やリスト3.10がその一例です。

<h1>Sample App</h1>
<p>
  This is the home page for the
  <a href="http://www.railstutorial.org/">Ruby on Rails Tutorial</a>
  sample application.
</p>

<h1>Help</h1>
<p>
  Get help on the Ruby on Rails Tutorial at the
  <a href="http://railstutorial.jp/help">Rails Tutorial help section</a>.
  To get help on this sample app, see the
  <a href="http://railstutorial.jp"><em>Ruby on Rails Tutorial</em>
  book</a>.
</p>

リスト3.9とリスト3.10の結果をそれぞれ図3.3と図3.4に示します。

図3.3 修正されたHomeページ

図3.4 修正されたHelpページ

3.3.1 最初のテスト

それではサンプルアプリケーションのAboutページの作成に取りかかります。やってみるとわかりますが、このページでは大したことは行わないので、このテストは驚くほど短く単純です。早速コラム3.3のガイドラインに沿って、テストを先に書くことにしましょう。続いてそのテストを実行して「失敗」することを確認し、実際のアプリケーションコードを書きます。

初めて書くテストがいきなり「テスト先行」というのは、Ruby on Railsの知識がある程度以上必要なため、少々ハードルが高い面もあります。今の段階でテストを書かせようとすると、尻込みしてしまう人もいるかもしれません。しかしご心配なく。面倒な部分は既にRailsが全部面倒を見てくれています。rails generate controller (リスト3.4) を実行した時点でテストファイルがちゃんと作成されているので、それを利用しましょう。

$ ls test/controllers/
static_pages_controller_test.rb

生成されたテストを見てみましょう (リスト3.11)。

require 'test_helper'

class StaticPagesControllerTest < ActionController::TestCase

  test "should get home" do
    get :home
    assert_response :success
  end

  test "should get help" do
    get :help
    assert_response :success
  end
end

現時点では、上のリスト3.11の文法をいきなり理解する必要はありません。今は「このファイルにはテストが2つ書かれている」ことを認識していただければ十分です。その2つのテストは、リスト3.4で生成したコントローラの2つのアクションであるHomeとHelpに対応して生成されたものです。それぞれのテストでは、アクションをgetして正常に動作することを確認します。この確認は「アサーション」(assertion: 主張、断言) と呼ばれる手法で行います。getは、HomeページやHelpページがいわゆる「GETリクエストを受け付ける」普通のWebページであるということを示します (コラム3.2)。その次の「response:success」は、実際にはHTTP のステータスコード (ここでは200 OK) を表します。つまり、以下のようなテストは

test "should get home" do
  get :home
  assert_response :success
end

言葉で表すと「Homeページのテスト。GETリクエストをhomeアクションに対して発行 (=送信) せよ。そうすれば、リクエストに対するレスポンスは[成功]になるはず。」となります。

テスティングサイクルの最初の一回しに取りかかる前に、まずは現在のテストスイートをそのまま実行して、問題なくパスすることを確認しておきます。テストの実行には、以下のようにrakeユーティリティを使用します (コラム2.1)⁷。

$ bundle exec rake test
2 tests, 2 assertions, 0 failures, 0 errors, 0 skips

テストスイートは期待どおりパス GREEN します (パスしたときにも色を表示できるようにするには、3.7.1のminitestレポーターをオプションで追加する必要があります)。ところで、テストの実行にはある程度時間がかかります。これには2つの要因が絡んでいます: (1) Spring serverを起動してRails環境を事前読み込みするのに時間がかかる。ただしこれは最初の1回だけです。(2) Rubyそのものの起動に時間がかかる (2番目の要因については、3.7.3で紹介するGuardを導入することで改善できます)。

3.3.2 Red

コラム3.3で解説したように、テスト駆動開発のサイクルは「失敗するテストを最初に書く」「次にアプリケーションのコードを書いてパスさせる」「必要ならリファクタリングする」のように進みます。多くのテストツールでは、テストの失敗を「レッド」、成功したときを「グリーン」で表します。ここから、このサイクルを「レッド・グリーン・リファクタリング」と呼ぶこともあります。これに従って最初のサイクルを完了させましょう。まず失敗するテストを書いてREDになるようにします。テストをGREENにするのは3.3.3、リファクタリングは3.4.3で行います⁸。

サイクルの記念すべき第一歩はAboutページ用の失敗するテストを書くことです。リスト3.11を参考にすれば、正しいテストコードを何となく想像できると思います。正しいテストコードをリスト3.13に示します。

require 'test_helper'

class StaticPagesControllerTest < ActionController::TestCase

  test "should get home" do
    get :home
    assert_response :success
  end

  test "should get help" do
    get :help
    assert_response :success
  end

  test "should get about" do
    get :about
    assert_response :success
  end
end

リスト3.13のハイライト行を見ると、他のHomeページ用テストやHelpページ用テストとほとんど同じであることがわかります。違いは「home」や「help」の部分が「about」に変わっている点だけです。

テストを実行すると、期待どおり失敗します。

$ bundle exec rake test
3 tests, 2 assertions, 0 failures, 1 errors, 0 skips

3.3.3 Green

テストがめでたく失敗した (RED) ので、今度はこのテストのエラーメッセージを頼りにテストがパスする (GREEN) ようにコードを書くことで、Aboutページを実装します。

失敗したテストのエラーメッセージをもっと詳しく見ていきましょう⁹。

$ bundle exec rake test
ActionController::UrlGenerationError:
No route matches {:action=>"about", :controller=>"static_pages"}

このエラーメッセージによれば、「指定されたアクション/コントローラの組み合わせに一致するルーティングが見当たらない」とあります。つまりルーティングファイルを修正する必要があるということです。リスト3.5のときと同じ要領で変更を行った結果をリスト3.16に示します。

Rails.application.routes.draw do
  get 'static_pages/home'
  get 'static_pages/help'
  get 'static_pages/about'
  .
  .
  .
end

リスト3.16のハイライト行では、/static_pages/aboutというURLへのGETリクエストが来たら、StaticPagesコントローラのaboutアクションに渡すようRailsに指示しています。

修正が終わったらテストスイートを再度実行します。まだREDのままです。しかし今度はメッセージが少し変わりました。

$ bundle exec rake test
AbstractController::ActionNotFound:
The action 'about' could not be found for StaticPagesController

このエラーメッセージから、「StaticPagesコントローラにaboutアクションがない」ということがわかります。リスト3.6のhomeやhelpと同じようにaboutアクションを追加します (リスト3.18)。

class StaticPagesController < ApplicationController

  def home
  end

  def help
  end

  def about
  end
end

今度はどうでしょう。まだREDですが、エラーメッセージがまた少し変わりました。

$ bundle exec rake test
ActionView::MissingTemplate: Missing template static_pages/about

今度はテンプレートがないようです。Railsではテンプレートといえばすなわち「ビュー」のことです。3.2.1で説明したように、homeというアクションはhome.html.erbというビューに関連付けられます。このビューはapp/views/static_pagesにあるので、ここにabout.html.erbというファイルを作ればよさそうです。

ファイルの作成方法はシステムの設定によってさまざまですが、たいていのテキストエディタでは、ディレクトリをCtrl+クリックすればコンテキストメニューに「New File」のようなメニューが表示されます。あるいはエディタの[File]メニューでファイルを作成して、このディレクトリに保存しても構いません。個人的にはUnixのtouchコマンドでファイルを作成するのがかっこいいと思います。

$ touch app/views/static_pages/about.html.erb

touchコマンドは本来ファイルやディレクトリのタイムスタンプだけを更新するためのコマンドなのですが、ファイルが存在しない場合には空ファイルを作成するという一種の副作用があります (クラウドIDEをご利用の場合は、touchでファイル作成後に1.3.1のようにファイルツリーの更新が必要な場合があります)。

とにかくabout.html.erbを正しいディレクトリに作成できたので、リスト3.19のとおりにコードを入力します。

<h1>About</h1>
<p>
  The <a href="http://www.railstutorial.org/"><em>Ruby on Rails
  Tutorial</em></a> is a
  <a href="http://railstutorial.jp">book</a> and
  <a href="http://screencasts.railstutorial.org/">screencast series</a>
  to teach web development with
  <a href="http://rubyonrails.org/">Ruby on Rails</a>.
  This is the sample application for the tutorial.
</p>

今度はrake testの結果はGREENになるはずです。

$ bundle exec rake test
3 tests, 3 assertions, 0 failures, 0 errors, 0 skips

もちろん、実際にブラウザを起動して、テストが正しく動いているかどうかを確かめることもできます (図3.5)。

図3.5 作成したAboutページ (/static_pages/about)

3.3.4 リファクタリング

テストがGREENになったので、安心してコードをリファクタリングできるようになりました。アプリケーションの開発が進むと、コードのどこからともなく「腐敗臭」が漂い始めます。コードや記法の統一が崩れて読みづらくなる、クラスやメソッドが何百行にも膨れ上がって読む気を削がれる、なぜこのコードがここにあるのか最早誰もその理由を思い出せなくなる、同じコードがあちこちにコピペされて少しずつ書き換えられ手に負えなくなる、などです。コンピュータにしてみればどんなに汚らしいコードであろうと、そこにあるがままに実行するだけですが、人間はそういうわけにはいきません。こまめにリファクタリングを繰り返してコードを常にすみずみまで美しくコンパクトに保ち、他の開発者や未来の自分の開発意欲を阻喪することのないようにしなければなりません。このサンプルアプリは生まれたてなので、今のところリファクタリングの必要な箇所はほぼどこにも見当たりません。しかし「一匹いれば30匹いると思え」、コードの腐敗臭はどんな小さな隙間からも忍び寄ってきます。こまめなリファクタリングの習慣をできるだけ早いうちに身につけるためにも、少々無理やりに3.4.3から始めることにします。

3.4.1 タイトルをテストする (Red)

ページタイトルを追加するために、典型的なWebページの構造を今一度おさらいしておきましょう (リスト3.21)。

<!DOCTYPE html>
<html>
  <head>
    <title>Greeting</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

リスト3.21の構造には次のものが含まれています。1) document type (doctype) は使用するHTMLのバージョン (ここではHTML5¹⁰) をブラウザに対して宣言します。2) headセクション。ここではtitleタグに囲まれた「Greeting」(=あいさつ) という文字があります。3) bodyセクション。ここには「Hello, world!」という文字列があります。「Hello, world!」はp (paragraph) タグの中にあります (HTMLではスペースやタブは無視されるので、インデントはあってもなくても大丈夫ですが、インデントがある方がHTMLのデータ構造を理解しやすくなります)。

表3.2の各タイトルについて簡単なテストを書きます (リスト3.13)。このテストで使用しているassert_selectメソッドでは、特定のHTMLタグが存在するかどうかをテストします (この種のアサーションメソッドはその名から「セレクタ」と呼ばれることもあります)¹¹。

assert_select "title", "Home | Ruby on Rails Tutorial Sample App"

上のセレクタは、<title>タグ内に「Home | Ruby on Rails Tutorial Sample App」という文字列があるかどうかをチェックします。同じ要領で3つの静的ページを書き換えます (リスト3.22)。

require 'test_helper'

class StaticPagesControllerTest < ActionController::TestCase

  test "should get home" do
    get :home
    assert_response :success
    assert_select "title", "Home | Ruby on Rails Tutorial Sample App"
  end

  test "should get help" do
    get :help
    assert_response :success
    assert_select "title", "Help | Ruby on Rails Tutorial Sample App"
  end

  test "should get about" do
    get :about
    assert_response :success
    assert_select "title", "About | Ruby on Rails Tutorial Sample App"
  end
end

(上のテストコードで繰り返し使われている「Ruby on Rails Tutorial Sample App」という文字列を一刻も早くリファクタリングしたくてたまらない方には、3.6の演習をおすすめします。)

リスト3.22どおりにテストを作成すると、テストスイートはREDになります。

$ bundle exec rake test
3 tests, 6 assertions, 3 failures, 0 errors, 0 skips

3.4.2 タイトルを追加する (Green)

今度は各ページにタイトルを追加して、3.4.1のテストがパスするようにしましょう。リスト3.21の基本HTML構造をカスタムのHomeページ (リスト3.9) に追加すると、リスト3.24のようになります。

<!DOCTYPE html>
<html>
  <head>
    <title>Home | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    <h1>Sample App</h1>
    <p>
      This is the home page for the
      <a href="http://www.railstutorial.org/">Ruby on Rails Tutorial</a>
      sample application.
    </p>
  </body>
</html>

このページの表示を図3.6に示します¹²。

図3.6 タイトルが付いたHomeページ

Helpページ (リスト3.10) やAboutページ (リスト3.19) についても、同じ要領でリスト3.25 や リスト3.26のようなコードに変更します。

<!DOCTYPE html>
<html>
  <head>
    <title>Help | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    <h1>Help</h1>
    <p>
      Get help on the Ruby on Rails Tutorial at the
      <a href="http://railstutorial.jp/help">Rails Tutorial help
      section</a>.
      To get help on this sample app, see the
      <a href="http://railstutorial.jp"><em>Ruby on Rails
      Tutorial</em> book</a>.
    </p>
  </body>
</html>

<!DOCTYPE html>
<html>
  <head>
    <title>About | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    <h1>About</h1>
    <p>
      The <a href="http://www.railstutorial.org/"><em>Ruby on Rails
      Tutorial</em></a> is a
      <a href="http://railstutorial.jp">book</a> and
      <a href="http://screencasts.railstutorial.org/">screencast series</a>
      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>

これでテストスイートはGREENになるはずです。

$ bundle exec rake test
3 tests, 6 assertions, 0 failures, 0 errors, 0 skips

3.4.3 レイアウトと埋め込みRuby (Refactor)

この節では、Railsのコントローラとアクションを使って3つの有効なページを生成することでさまざまなことを達成しました。しかしそれらは単純な静的ページであり、またRailsの能力を十分に発揮できていません。しかも、コードが甚だしく重複しています。

• ページのタイトルがどれもほぼ同じ (完全にではないが)。
• 「Ruby on Rails Tutorial Sample App」という文字が3つのタイトルで繰り返し使われている。
• HTMLの構造全体が各ページで重複している。

同じコードを繰り返すことはRubyの「DRY」(Don't Repeat Yourself: 繰り返すべからず) という原則に反します。この節では、繰り返しを追放してコードをDRY (=よく乾かす) にしましょう。最後に3.4.2のテストを実行して、タイトルを壊していないことを確認します。

上の話と一見矛盾するようですが、最初にコードを若干追加して、現在は「ほぼ」同じになっているページのタイトルを「完全に」同じにしておきます。この方が、コードの重複を一括で取り除けるからです。

重複を取り除くテクニックのひとつとして、ビューで「埋め込みRuby」(Embedded Ruby) を使用できます。Home、Help、Aboutページには可変要素があるので、Railsのprovide関数を使用してタイトルをページごとに変更します。それでは、home.html.erbビューのコードを、リスト3.28のように、タイトルに含まれる"Home"という文字を置き換え、動作を確認しましょう。

<% provide(:title, "Home") %>
<!DOCTYPE html>
<html>
  <head>
    <title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    <h1>Sample App</h1>
    <p>
      This is the home page for the
      <a href="http://www.railstutorial.org/">Ruby on Rails Tutorial</a>
      sample application.
    </p>
  </body>
</html>

リスト3.28は、ERBと呼ばれている、Rubyの埋め込みコードの最初の例です (これで、HTMLビューのファイルの拡張子が.html.erbとなっている理由をおわかりいただけたと思います)。ERBはWebページに動的な要素を加えるときに使うテンプレートシステムです¹³。

<% provide(:title, "Home") %>

上のコードでは<% ... %>という記法が使用されており、その中からRailsのprovide関数を呼び出しています。関数の引数では、"Home"という文字列と:titleというラベルを関連付けています¹⁴。そしてタイトルの部分では、上の記法と連携する「<%= ... %>」というよく似た記法を使用し、その中でRubyのyield関数を呼び出しています¹⁵。この関数によって、テンプレートのその部分に実際のタイトルが挿入されます。

<title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>

この2つのERBの違いは次のとおりです。<% ... %>と書くと、中に書かれたコードを単に実行するだけで何も出力しません。<%= ... %>のように等号を追加すると、中のコードの実行結果がテンプレートのその部分に挿入されます。ERBでビューをこのように書き換えても、ページの表示結果は以前とまったく同じです。タイトルの可変部分がERBによって動的に生成されている点だけが異なります。

3.4.2のテストを実行してこの改修を確認すれば、今度もGREENになるはずです。

$ bundle exec rake test
3 tests, 6 assertions, 0 failures, 0 errors, 0 skips

続いて、HelpページとAboutページも同様に変更します (リスト3.30、リスト3.31)。

<% provide(:title, "Help") %>
<!DOCTYPE html>
<html>
  <head>
    <title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    <h1>Help</h1>
    <p>
      Get help on the Ruby on Rails Tutorial at the
      <a href="http://railstutorial.jp/help">Rails Tutorial help
      section</a>.
      To get help on this sample app, see the
      <a href="http://railstutorial.jp"><em>Ruby on Rails
      Tutorial</em> book</a>.
    </p>
  </body>
</html>

<% provide(:title, "About") %>
<!DOCTYPE html>
<html>
  <head>
    <title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    <h1>About</h1>
    <p>
      The <a href="http://www.railstutorial.org/"><em>Ruby on Rails
      Tutorial</em></a> is a
      <a href="http://railstutorial.jp">book</a> and
      <a href="http://screencasts.railstutorial.org/">screencast series</a>
      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>

タイトルの可変部分をERBを使って置き換えたので、現在それぞれのページはだいたい以下のような構造になっています。

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

こうして見ると、HTMLの構造はtitleタグの内容も含めてどのページも完全に同じです。異なる点があるとすれば、bodyタグの内側のコンテンツだけです。

これはもうリファクタリングしてHTMLの重複した構造をDRYにするしかないでしょう。ご想像のとおり、Railsにはそのためにapplication.html.erbという名前のレイアウトファイルがあります。最初3.4でこのレイアウトファイルの名前をわざわざ変えておきましたが、いよいよ以下のコマンドでファイル名を元に戻すことにしましょう。

$ mv layout_file app/views/layouts/application.html.erb

このレイアウトファイルを有効にするには、前述のデフォルトのタイトル部分を以下のERBコードに差し替えます。

<title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>

変更の結果、レイアウトファイルはリスト3.32のようになります。

<!DOCTYPE html>
<html>
  <head>
    <title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</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>

上のコードにある、以下の特殊なコードにご注目ください。

<%= yield %>

このコードは、各ページの内容をレイアウトに挿入するためのものです。ここでは、このコードの詳細な動作を正確に理解することは重要ではありません。レイアウトを使用するうえでは、/static_pages/homeにアクセスすると、home.html.erbの内容がHTMLに変換され、<%= yield %>の位置に挿入されるということだけ理解しておけば問題ありません。

Railsのデフォルトのレイアウトには、以下の行が追加されていることにもご注目ください。

<%= stylesheet_link_tag ... %>
<%= javascript_include_tag "application", ... %>
<%= csrf_meta_tags %>

上の3つのERBは、それぞれスタイルシート、JavaScript、csrf_meta_tagsメソッドをページ内で展開するためのものです。スタイルシートとJavaScriptは、Asset Pipeline (5.2.1) の一部です。csrf_meta_tagsは、Web攻撃手法のひとつであるクロスサイトリクエストフォージェリー (cross-site request forgery: CSRF)を防ぐために使われるRailsのメソッドです。

もちろん、リスト3.28、リスト3.30、 リスト3.31のビューには、レイアウトと重複するHTMLがまだ残っているので、それらを削除して、内部のコンテンツだけ残します。この改修が終わると、 リスト3.33、リスト3.34、リスト3.35のように実に簡潔で美しいコードになります。

<% provide(:title, "Home") %>
<h1>Sample App</h1>
<p>
  This is the home page for the
  <a href="http://www.railstutorial.org/">Ruby on Rails Tutorial</a>
  sample application.
</p>

<% provide(:title, "Help") %>
<h1>Help</h1>
<p>
  Get help on the Ruby on Rails Tutorial at the
  <a href="http://railstutorial.jp/help">Rails Tutorial help section</a>.
  To get help on this sample app, see the
  <a href="http://railstutorial.jp"><em>Ruby on Rails Tutorial</em>
  book</a>.
</p>

<% provide(:title, "About") %>
<h1>About</h1>
<p>
  The <a href="http://www.railstutorial.org/"><em>Ruby on Rails
  Tutorial</em></a> is a
  <a href="http://railstutorial.jp">book</a> and
  <a href="http://screencasts.railstutorial.org/">screencast series</a>
  to teach web development with
  <a href="http://rubyonrails.org/">Ruby on Rails</a>.
  This is the sample application for the tutorial.
</p>

上のように定義されたビューは、Home、Help、Aboutページの表示は以前と変わりませんが、コードの重複が大きく削減されました。

この節で行ったようなちっぽけなリファクタリングですら、実際にやってみると大小さまざまなエラーが発生します。ベテラン開発者ほどこのことを骨の髄まで理解しており、どんな小さなリファクタリングでもあなどったりしません。テストスイートをきちんと整備しておくことがいかに重要であるか、皆さんにもご理解いただけると思います。開発のごく初期の段階なら全ページを目視でひとつひとつ確認して回ることもできるかもしれませんが、そんな方法ではじきに手に負えなくなります。このアプリでは必要なテストスイートが整備されているので、今度もGREENになることを確認するだけでOKです。

$ bundle exec rake test
3 tests, 6 assertions, 0 failures, 0 errors, 0 skips

もちろん厳密に言えば、テストがパスしたというだけではそのコードが本当に正しいのかどうかの証明にはなりません。しかし正しいコードに確実に近づくことができ、正しい可能性も上がります。何よりも、テストがあれば今後発生するバグを防ぐためのセーフティネットになります。

3.4.4 ルーティングの設定

サイトのページのカスタマイズが終わって、テストスイートも軌道に乗ってきたので、今のうちにアプリケーションルートのルーティングを設定しておきましょう。1.3.4と2.2.2でやったように、ルーティングを設定するにはroutes.rbファイルを編集して、ルート「/」とWebページを結び付けます。結び付ける相手はHomeページです (3.1でApplicationコントローラにhelloアクションを追加した場合は、今のうちにアクションを削除しておくことをおすすめします)。変更結果をリスト3.37に示します。ここでは、リスト3.5のgetルールを以下のコードに置き換えています。

root 'static_pages#home'

上のルールに置き換えると、static_pages/homeというURLからstatic_pages#homeというコントローラ/アクションへの対応付けが変わり、ルート「/」へのGETリクエストがStaticPagesコントローラのhomeアクションにルーティングされます。変更後のルーティングファイルを図3.7に示します。リスト3.37のコードにすると、static_pages/homeにアクセスしても動作しなくなります。

Rails.application.routes.draw do
  root 'static_pages#home'
  get  'static_pages/help'
  get  'static_pages/about'
end

図3.7 ルートURLにアクセスするとHomeページが表示される

3.5.1 本章のまとめ

• 新しいRailsアプリケーションをゼロから作成したのはこれで3度目。今回も必要なgemのインストール、リモートリポジトリへのプッシュ、production環境まで行った。
• コントローラを新規作成するためのrailsのスクリプトはrails generate controller ControllerName <action name (省略可)>。訳注: コントローラ名はキャメルケース、アクション名はスネークケースにする。
• 新しいルーティングはconfig/routes.rbファイルで定義する。
• Railsのビューでは、静的HTMLの他にERB (埋め込みRuby: Embedded RuBy) も使用できる。
• 常に自動化テストを使用して新機能開発を進めることで、自信を持ってリファクタリングできるようになり、回帰バグもいちはやくキャッチできるようになる。
• テスト駆動開発では「レッド・グリーン・リファクタリング」サイクルを繰り返す。
• Railsのレイアウトでは、アプリケーションのページの共通部分をテンプレートに置くことでコードの重複を解決することができる。

3.7.1 minitestレポーター

Railsのデフォルトのテストで、必要に応じてREDやGREENを表示するためには、リスト3.40のコードをテスト用ヘルパーファイルに追加するだけです¹⁸。このコードでは、リスト3.2で追加したminitest-reporters gemを利用しています。

ENV['RAILS_ENV'] ||= 'test'
require File.expand_path('../../config/environment', __FILE__)
require 'rails/test_help'
require "minitest/reporters"
Minitest::Reporters.use!

class ActiveSupport::TestCase
  # Setup all fixtures in test/fixtures/*.yml for all tests in alphabetical
  # order.
  fixtures :all

  # Add more helper methods to be used by all tests here...
end

この変更により、Cloud IDE上の表示がREDからGREENに変わります (図3.8)。

図3.8: Cloud IDE上で表示をREDからGREENに変える

3.7.2 Backtrace silencer

テストが失敗した時に、テスト失敗の道筋をアプリケーション全体にわたってたどるスタックトレース (バックトレース) が表示されます。バックトレースは問題を追跡するうえでは非常に便利なのですが、クラウドIDEなど一部のシステムでは、このトレースがgemの依存関係やRails自身にまで及ぶことがあります。そうなると大量のスタックトレースが出力されて非常に不便です。gemの依存関係を調べているのでもなければ、開発しているアプリケーションで問題の原因を追跡中に大量のメッセージが出力されても、邪魔なだけです。

こうした不要な出力行を除去するために、バックトレースをフィルタします。これを行うにはmini_backtrace gem (リスト3.2) とbacktrace silencerを組み合わせます。クラウドIDEの場合、そうした不要な行ではほとんどの場合rvm (=Ruby Version Manager) という文字がパスに含まれているので、これを利用してフィルタします (リスト3.41)。

# Be sure to restart your server when you modify this file.

# You can add backtrace silencers for libraries that you're using but don't
# wish to see in your backtraces.
Rails.backtrace_cleaner.add_silencer { |line| line =~ /rvm/ }

# You can also remove all the silencers if you're trying to debug a problem
# that might stem from framework code.
# Rails.backtrace_cleaner.remove_silencers!

リスト3.41のコメント冒頭にあるように、backtrace silencerを追加した後は必ずRails webサーバーを再起動してください。

3.7.3 Guardによるテストの自動化

rake testコマンドは、テストをする度にコマンドラインに移動して手動でコマンドを実行しなければならない点が面倒です。この不便さを取り除くために、Guardを使ってテストを自動的に実行させるようにしてみましょう。Guardは、ファイルシステムの変更を監視し、たとえばstatic_pages_test.rbファイルなどを変更すると自動的にテストを実行してくれるツールです。また、テストファイルだけでなく、home.html.erbファイルが変更されるとstatic_pages_test.rbが自動的に実行されるようにGuardを設定することもできます。

実はすでに、リスト3.2のGemfileでguard gemをアプリケーション内に取り込んでいます。したがって、あとは初期化するだけで動かすことができます。

$ bundle exec guard init
Writing new Guardfile to /home/ubuntu/workspace/sample_app/Guardfile
00:51:32 - INFO - minitest guard added to Guardfile, feel free to edit it

統合テストとビューが更新されたら自動的に適切なテストが実行されるように、生成されたGuardfileを編集します (リスト3.42)。(やや長くて応用的な設定なので、リスト3.42をコピペしてしまった方がよいでしょう)

# Defines the matching rules for Guard.
guard :minitest, spring: true, all_on_start: false do
  watch(%r{^test/(.*)/?(.*)_test\.rb$})
  watch('test/test_helper.rb') { 'test' }
  watch('config/routes.rb')    { integration_tests }
  watch(%r{^app/models/(.*?)\.rb$}) do |matches|
    "test/models/#{matches[1]}_test.rb"
  end
  watch(%r{^app/controllers/(.*?)_controller\.rb$}) do |matches|
    resource_tests(matches[1])
  end
  watch(%r{^app/views/([^/]*?)/.*\.html\.erb$}) do |matches|
    ["test/controllers/#{matches[1]}_controller_test.rb"] +
    integration_tests(matches[1])
  end
  watch(%r{^app/helpers/(.*?)_helper\.rb$}) do |matches|
    integration_tests(matches[1])
  end
  watch('app/views/layouts/application.html.erb') do
    'test/integration/site_layout_test.rb'
  end
  watch('app/helpers/sessions_helper.rb') do
    integration_tests << 'test/helpers/sessions_helper_test.rb'
  end
  watch('app/controllers/sessions_controller.rb') do
    ['test/controllers/sessions_controller_test.rb',
     'test/integration/users_login_test.rb']
  end
  watch('app/controllers/account_activations_controller.rb') do
    'test/integration/users_signup_test.rb'
  end
  watch(%r{app/views/users/*}) do
    resource_tests('users') +
    ['test/integration/microposts_interface_test.rb']
  end
end

# Returns the integration tests corresponding to the given resource.
def integration_tests(resource = :all)
  if resource == :all
    Dir["test/integration/*"]
  else
    Dir["test/integration/#{resource}_*.rb"]
  end
end

# Returns the controller tests corresponding to the given resource.
def controller_test(resource)
  "test/controllers/#{resource}_controller_test.rb"
end

# Returns all tests for the given resource.
def resource_tests(resource)
  integration_tests(resource) << controller_test(resource)
end

上のコードにある以下の行にご注目ください。

guard :minitest, spring: true, all_on_start: false do

この行ではGuardからSpringサーバーを使用して読み込み時間を短縮しています (SpringはRailsの機能のひとつです)。また、開始時にテストスイートをフルで実行しないようGuardに指示しています。

Guard使用時のSpringとGitの競合を防ぐには、.gitignoreファイルにspring/ディレクトリを追加します。.gitignoreはGitの設定ファイルのひとつで、ここで指定されたファイルはGitレポジトリに追加されなくなります。クラウドIDEでは以下の操作を行います。

1. ナビゲーションパネルの右上のにある歯車アイコンをクリックします (図3.9)。
2. [Show hidden files] を選択して、アプリケーションのルートディレクトリにある.gitignoreファイルを表示します (図3.10).
3. .gitignoreファイル (図3.11) をダブルクリックして開き、リスト3.43のように更新します。

図3.9 ファイルナビゲーターにある (あまり目立たない) ギアのアイコン

図3.10 ファイルナビゲーター内の隠しファイルを表示する

図3.11 隠れている.gitignoreファイルを表示する

# See https://help.github.com/articles/ignoring-files for more about ignoring
# files.
#
# If you find yourself ignoring temporary files generated by your text editor
# or operating system, you probably want to add a global ignore instead:
#   git config --global core.excludesfile '~/.gitignore_global'

# Ignore bundler config.
/.bundle

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

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

# Ignore Spring files.
/spring/*.pid

Springサーバーは本節の執筆時点では若干不安定な点が残っていて、Springのプロセスが起動したまま多数残留すると、テストのパフォーマンスが低下してしまうことがあります。テストの実行が異常に遅くなってきたと感じたら、システムプロセスをチェックしてSpringを必要に応じてkillするとよいでしょう (コラム3.4)。

  $ ps aux

  $ ps aux | grep spring
  ubuntu 12241 0.3 0.5 589960 178416 ? Ssl Sep20 1:46
  spring app | sample_app | started 7 hours ago

  $ kill -15 12241

  $ spring stop

  $ pkill -15 -f spring

Guardの設定が完了したら、新しいターミナルを開き (1.3.2でやったようにRailsサーバーのターミナルと別にするのがポイントです)、以下をコマンドラインで実行します

$ bundle exec guard

リスト3.42のルールは本チュートリアルに最適化したものなので、たとえばコントローラのファイルを変更すると、Guardは即座にそれを検出して、そのコントローラの統合テストを自動実行します。テストを変更ファイルだけではなく、フルで実行したい場合は、guard>プロンプトでReturnキーを押します (このとき、Springサーバーに接続できないなどのエラーが表示されることがあります。問題を修正するには、もう一度Returnキーを押します)。

Guardを終了するにはCtrl-Dキーを押します。Guardに他のマッチャーを追加する方法については、リスト3.42の例、Guard README、Guard wikiを参照してください。