3.2.1 静的なページの生成

静的なページの作成は、第2章でscaffold生成に使った generate スクリプトで、コントローラを生成することから始めます。

このコントローラは静的なページを扱うためにしか使わないので、コントローラ名を「Static Pages」に決め、StaticPagesのようにスペースなしで表記することにします。続いて、Homeページ、Helpページ、Aboutページに使うアクションもそれぞれ作成することにし、アクション名はすべて小文字のhome、help、aboutにします。generateスクリプトではアクション名をまとめて指定することもできるので、コマンドラインでHomeページとHelpページ用のアクションもまとめて生成することにします。なお、Aboutページだけは学習のため、あえてコマンドラインでは作成せず、3.3で手動で追加することにします。

これらの要素を盛り込んだStaticPagesコントローラ生成コマンドと実行結果をリスト 3.6に示します。

$ rails generate controller StaticPages home help
      create  app/controllers/static_pages_controller.rb
       route  get "static_pages/home"
get "static_pages/help"
      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

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

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

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

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

$ git push

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

リスト 3.6のコマンドでは、コントローラ名をStaticPagesのように単語ごとに先頭を大文字にした形式で渡していることに注目してください⁶。こうすると、StaticPagesコントローラ名を「static_pages」のように小文字かつ区切りにアンダースコア文字を使った形式に変換したファイルstatic_pages_controller.rbを自動的に生成します⁷。

ただし、上のような命名は単なる慣習に過ぎないので、実際にはどちらの形式でも指定できます。実際、コマンドライン上で次のようにコントローラ名を「static_pages」と入力しても、

$ rails generate controller static_pages ...

先ほどと同様にstatic_pages_controller.rbというコントローラが生成されます。これは、Rubyがクラス名にStaticPagesのような形式を使う慣習があり（詳しくは4.4で説明します）、また、そうした命名が好まれているためです。これらの慣習に必ず従わなければいけないわけではありません。

同様にRubyでは、ファイル名を「static_pages」のような形式で統一する慣習があります。このためRailsのgenerateスクリプトでは、underscoreメソッドを使ってStaticPagesというクラス名を「static_pages」に変換してファイル名として使っているのです。

ところで、もし自動生成に失敗するようなことがあれば、それは元に戻す処理を学ぶ良い機会にもなりますね。コラム 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

  $ rails db:migrate

  $ rails db:rollback

  $ rails db:migrate VERSION=0

リスト 3.6のようにStaticPagesコントローラを生成すると、（config/routes.rb）ファイルが自動的に更新されます。これは1.3.4でhelloアプリのルート（root）ルーティングを編集したときにリスト 1.11で確認し、本章でもリスト 3.5で確認しました。このルーティングファイルはルーターの実装を受け持ち（図 2.13）、URLとWebページの対応関係を定義します。このルーティングファイルはRailsのconfigディレクトリの下に置かれます。このディレクトリには、Railsの設定ファイルがまとめて置かれます（図 3.4）。

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

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

Rails.application.routes.draw do
  get  "static_pages/home"
  get  "static_pages/help"
  root "application#hello"

end

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

get "static_pages/home"

このルールは、/static_pages/homeというURLに対するリクエストを、StaticPagesコントローラのhomeアクションと結びつけています。今回はgetと書かれているため、GETリクエストを受け取ったときに対応するアクションを結びつけています。なお、ここでいうGETリクエストとは、HTTP（HyperText Transfer Protocol） が対応しているメソッドの1つです（コラム 3.2）。

今回の場合は、StaticPagesコントローラ内にhomeアクションを追加したので、/static_pages/homeにアクセスすることでページを取得（GET）できるようになりました。Railsのdevelopmentサーバーが起動していない場合は、1.3.2に従って次のようにサーバーを起動します。

$ rails server

Railsサーバーが立ち上がった状態で、/static_pages/homeにアクセスして結果を表示します（図 3.5）。

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

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

class StaticPagesController < ApplicationController
  def home
  end

  def help
  end
end

リスト 3.8の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.6をもう一度注意深く読んでみると、アクションとビューの関係を推測できるでしょう。homeアクションはhome.html.erbというビューに対応しています。.erbの詳細については3.4で説明しますが、ファイル名に.htmlが含まれていることからわかるように、基本的にはHTMLと同じような構造になっています（リスト 3.9）。

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

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

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

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

3.2.2 静的なページの調整

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

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

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

リスト 3.11とリスト 3.12の結果をそれぞれ図 3.6と図 3.7に示します。

図 3.6: 修正されたHomeページ

図 3.7: 修正されたHelpページ

3.3.1 最初のテスト

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

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

$ ls test/controllers/
static_pages_controller_test.rb

生成されたテストを見てみましょう（リスト 3.13）。

require "test_helper"

class StaticPagesControllerTest < ActionDispatch::IntegrationTest

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

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

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

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

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

テストを書くサイクルに入る前に、まずは現在のテストスイートをそのまま実行して、問題なくパスすることを確認しておきましょう。テストの実行には次のようにrailsコマンドを使います。

$ rails db:migrate     # システムによっては必要
$ rails test
2 runs, 2 assertions, 0 failures, 0 errors, 0 skips

テストスイートは期待どおり成功（ green ）します（システムによっては、成功時に色を表示させるためには、3.6.1で説明するminitest reportersを追加する必要がありますが、単に見やすくするためのものなので必須ではありません）。この箇所も含めて、本チュートリアルでは重要な部分に注目しやすくするため、テストの出力結果の一部を省略しています。

ところで、一部のシステムでは以下のようなファイルがdbディレクトリの下に生成されていることがあります。

/db/test.sqlite3-0

この生成ファイルがGitリポジトリに登録されると邪魔なので、Gitのセットアップ（1.4.1）で紹介した.gitignoreファイルには、デフォルトでリスト 3.15の記述があります。見つからない場合は登録を防ぐために追加することをオススメします。

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

3.3.2 Red

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

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

require "test_helper"

class StaticPagesControllerTest < ActionDispatch::IntegrationTest

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

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

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

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

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

$ rails test
3 runs, 2 assertions, 0 failures, 1 errors, 0 skips

3.3.3 Green

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

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

$ rails test
NameError: undefined local variable or method `static_pages_about_url'

このエラーメッセージによれば、「AboutページへのURLが見つからない」とあります。このメッセージをヒントに、ルーティングファイルを修正してみましょう。リスト 3.7のときと同じ要領で、変更を行った結果をリスト 3.19に示します。

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

リスト 3.19のハイライト行では、/static_pages/aboutというURLに対してGETリクエストが来たら、StaticPagesコントローラのaboutアクションに渡すようRailsに指示しています。この結果、自動的に次のようなヘルパーが使えるようになります。

static_pages_about_url

修正が終わったらテストスイートをもう一度実行してみましょう。まだ red のままです。しかし今度はメッセージが少し変わりました。

$ rails test
AbstractController::ActionNotFound:
The action 'about' could not be found for StaticPagesController

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

class StaticPagesController < ApplicationController

  def home
  end

  def help
  end

  def about
  end
end

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

$ rails test
ActionController::MissingExactTemplate: StaticPagesController#about
is missing a template for request formats: text/html

今度はテンプレートがないようです。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のようにファイルツリーを更新する必要があります）。こういったテクニックを少しずつ身に付けておくのが「熟練」への道です（コラム 1.2）。

さて、適切なディレクトリにabout.html.erbファイルを作成したら、リスト 3.22のとおりに内容を書き換えます。

<h1>About</h1>
<p>
  <a href="https://railstutorial.jp/">Ruby on Rails Tutorial</a>
  is a <a href="https://railstutorial.jp/#ebook">book</a> and
  <a href="https://railstutorial.jp/screencast">screencast</a>
  to teach web development with
  <a href="https://rubyonrails.org/">Ruby on Rails</a>.
  This is the sample app for the tutorial.
</p>

今度のrails testの結果は green になるはずです。

$ rails test
3 runs, 3 assertions, 0 failures, 0 errors, 0 skips

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

図 3.8: 新しいAboutページ（/static_pages/about）

3.3.4 Refactor

テストが green になったので、安心してコードをリファクタリングできるようになりました。

アプリケーションの開発を繰り返すうちに、コードのどこからともなく「腐敗臭」が漂い始めます。コードや記法の統一が崩れて読みづらくなる、クラスやメソッドが何百行にも膨れ上がって読む気を削がれる、なぜこのコードがここにあるのか、もはや誰もその理由を思い出せなくなる、同じコードがあちこちにコピペされて少しずつ書き換えられ手に負えなくなる、などです。

コンピュータは、どんなに汚いコードであっても書かれた通りにひたすら実行しますが、人間はそういうわけにはいきません。こまめにリファクタリングを繰り返してコードを常にすみずみまで美しくコンパクトに保ち、他の開発者や未来の自分の開発意欲を削ぐことのないようにしなければなりません。このサンプルアプリは生まれたてなので、今のところリファクタリングの必要な箇所はほとんど見当たりません。しかし「1匹いれば30匹いると思え」ということわざのように、コードの腐敗臭はどんな小さな隙間からも忍び寄ってきます。こまめなリファクタリングの習慣をできるだけ早いうちに身につけるためにも、あえて3.4.3から始めることにします。

3.4.1 タイトルをテストする（Red）

ページタイトルを追加する前に、HTMLについて今一度おさらいしておきましょう。典型的なWebページは、リスト 3.24のようなHTMLの構造を持っています（HTMLの詳細は 『HTML編』を参照）。

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

リスト 3.24の構造には次の3つが含まれています。 1）document type（doctype）は使用するHTMLのバージョン（ここではHTML5）をブラウザに対して宣言します¹¹。 2）headセクション。ここではtitleタグに囲まれた「Greeting」（=あいさつ）という文字があります。 3）bodyセクション。ここには「Hello, world!」という文字列があります。「Hello, world!」は、p（paragraph）タグの中にあります¹²。

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

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

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

require "test_helper"

class StaticPagesControllerTest < ActionDispatch::IntegrationTest

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

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

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

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

$ rails test
3 runs, 6 assertions, 3 failures, 0 errors, 0 skips

3.4.2 タイトルを追加する（Green）

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

<!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="https://railstutorial.jp/">Ruby on Rails Tutorial</a>
      sample application.
    </p>
  </body>
</html>

このページの表示を図 3.9に示します¹⁴。

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

Helpページ（リスト 3.12）やAboutページ（リスト 3.22）についても、同じ要領でリスト 3.28 や リスト 3.29のようなコードに変更します。

<!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="https://railstutorial.jp/help">Rails Tutorial help
      page</a>.
      To get help on this sample app, see the
      <a href="https://railstutorial.jp/#ebook">
      <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>
      <a href="https://railstutorial.jp/">Ruby on Rails Tutorial</a>
      is a <a href="https://railstutorial.jp/#ebook">book</a> and
      <a href="https://railstutorial.jp/screencast">screencast</a>
      to teach web development with
      <a href="https://rubyonrails.org/">Ruby on Rails</a>.
      This is the sample app for the tutorial.
    </p>
  </body>
</html>

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

$ rails test
3 runs, 6 assertions, 0 failures, 0 errors, 0 skips

require "test_helper"

class StaticPagesControllerTest < ActionDispatch::IntegrationTest

  def setup
    @base_title = "Ruby on Rails Tutorial Sample App"
  end

  test "should get home" do
    get static_pages_home_url
    assert_response :success
    assert_select "title", "Home | #{@base_title}"
  end

  test "should get help" do
    get static_pages_help_url
    assert_response :success
    assert_select "title", "Help | #{@base_title}"
  end

  test "should get about" do
    get static_pages_about_url
    assert_response :success
    assert_select "title", "About | #{@base_title}"
  end
end

3.4.3 レイアウトとERB（Refactor）

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

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

同じコードを何度も繰り返し書くと、Rubyの「DRY」（Don’t Repeat Yourself: 繰り返すべからず）という原則に反します。この節では、繰り返し（重複）を追放してコードをDRYにしましょう。最後に3.4.2のテストを再度実行して、タイトルが正しいことを確認します。

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

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

<% 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="https://railstutorial.jp/">Ruby on Rails Tutorial</a>
      sample application.
    </p>
  </body>
</html>

リスト 3.32は、ERB（または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 になるはずです。

$ rails test
3 runs, 6 assertions, 0 failures, 0 errors, 0 skips

続いて、HelpページとAboutページも同様に変更します（リスト 3.34、リスト 3.35）。

<% 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="https://railstutorial.jp/help">Rails Tutorial help
      section</a>.
      To get help on this sample app, see the
      <a href="https://railstutorial.jp/#ebook">
      <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>
      <a href="https://railstutorial.jp/">Ruby on Rails Tutorial</a>
      is a <a href="https://railstutorial.jp/#ebook">book</a> and
      <a href="https://railstutorial.jp/screencast">screencast</a>
      to teach web development with
      <a href="https://rubyonrails.org/">Ruby on Rails</a>.
      This is the sample application for the tutorial.
    </p>
  </body>
</html>

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

<% provide(:title, "Page 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.36のようになります。

<!DOCTYPE html>
<html>
  <head>
    <title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <meta charset="utf-8">
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>

    <%= stylesheet_link_tag "application", "data-turbo-track": "reload" %>
    <%= javascript_importmap_tags %>
  </head>

  <body>
    <%= yield %>
  </body>
</html>

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

<%= yield %>

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

また、リスト 3.36には「文字セット（character set）」を表すmetaタグも含まれています。ここでは、UTF-8という文字エンコーディングが指定されています。UTF-8エンコーディングは、「™」や「✓」などのUnicode文字をサポートします。

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

<%= csrf_meta_tags %>
<%= csp_meta_tag %>
<%= stylesheet_link_tag ... %>
<%= javascript_importmap_tags %>

上のERBは、スタイルシートとJavaScriptをページ内にインクルードする（=含める）ためのものです。スタイルシートとJavaScriptは、アセットパイプライン（5.2.1）の一部であり、クロスサイトスクリプティング攻撃を緩和するコンテンツセキュリティポリシー（Content Security Policy: CSP）を実装するcsp_meta_tagと、クロスサイトリクエストフォージェリー（Cross-Site Request Forgery: CSRF）攻撃を緩和するcsrf_meta_tagsも含みます。Railsのような長年実績を積んでいるフレームワークを使うと、開発者がこのようなセキュリティ対策を気にせずに済むのが大きなメリットです。

テストが無事パスしても、まだやることは残っています。リスト 3.32、リスト 3.34、 リスト 3.35のビューには、レイアウトと重複する不要なHTML構造がまだ残っていて、このままではHTMLマークアップが壊れてしまうので、この不要なHTML構造を削除して、内部のコンテンツだけ残します。この改修が終わると、リスト 3.37、リスト 3.38、リスト 3.39のように実に簡潔で美しいコードになります。

<% provide(:title, "Home") %>
<h1>Sample App</h1>
<p>
  This is the home page for the
  <a href="https://railstutorial.jp/">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="https://railstutorial.jp/help">Rails Tutorial Help page</a>.
  To get help on this sample app, see the
  <a href="https://railstutorial.jp/#ebook"><em>Ruby on Rails Tutorial</em>
  book</a>.
</p>

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

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

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

$ rails test
3 runs, 6 assertions, 0 failures, 0 errors, 0 skips

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

<% provide(:title, "Contact") %>
<h1>Contact</h1>
<p>
  Contact the Ruby on Rails Tutorial about the sample app at the
  <a href="https://railstutorial.jp/contact">contact page</a>.
</p>

3.4.4 ルーティングの設定

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

root "application#hello"

次のコードに置き換えています。

root "static_pages#home"

上のルールに置き換えるとコントローラ/アクションへの対応付けが変わり、ルート「/」へのGETリクエストがStaticPagesコントローラのhomeアクションにルーティングされます。無事に変更できれば、図 3.10のようになるはずです。

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

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

require "test_helper"

class StaticPagesControllerTest < ActionDispatch::IntegrationTest

  test "should get root" do
    get （コードを書き込む）
    assert_response （コードを書き込む）
  end

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

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

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

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

3.5.1 本章のまとめ

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

3.6.1 minitest reporters

red や green の色は、クラウドIDEなど多くのシステムでは何もしなくても適切に表示されますが、minitest reportersを使うとテスト結果の出力を見やすくフォーマットしてくれます。そのため筆者は、リスト 3.45 のコードをテストヘルパーファイルに追加することで、リスト 3.2のGemfileにあるminitest-reporters gemを利用することをオススメします。

ENV["RAILS_ENV"] ||= "test"
require_relative "../config/environment"
require "rails/test_help"
require "minitest/reporters"
Minitest::Reporters.use!

class ActiveSupport::TestCase
  # 指定のワーカー数でテストを並列実行する
  parallelize(workers: :number_of_processors)

  # test/fixtures/*.ymlにあるすべてのfixtureをセットアップする
  fixtures :all

  # （すべてのテストで使うその他のヘルパーメソッドは省略）
end

この変更により、テスト結果に合わせて red や green の色付きの表示になります（図 3.12）。

図 3.12: 色付きで表示されたテスト結果

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

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

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

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

統合テストとビューが更新されたら自動的に適切なテストが実行されるように、生成されたGuardfileを編集します（リスト 3.46）。柔軟性を最大にするため、チュートリアルの参照用アプリケーションに記載されているのと同じバージョンのGuardfileをお使いになることをオススメします。本チュートリアルをオンラインでお読みの方は、リスト 3.46で正確な書き方を参照できます。

• Guardfileの参照: railstutorial.org/guardfile

  require "active_support/inflector"
  # Guardのマッチング規則を定義
  guard :minitest, all_on_start: false do
    watch(%r{^test/(.*)/?(.*)_test\.rb$})
    watch('test/test_helper.rb') { 'test' }
    watch('config/routes.rb') { interface_tests }
    watch(%r{app/views/layouts/*}) { interface_tests }
    watch(%r{^app/models/(.*?)\.rb$}) do |matches|
      ["test/models/#{matches[1]}_test.rb",
       "test/integration/microposts_interface_test.rb"]
    end
    watch(%r{^test/fixtures/(.*?)\.yml$}) do |matches|
      "test/models/#{matches[1].singularize}_test.rb"
    end
    watch(%r{^app/mailers/(.*?)\.rb$}) do |matches|
      "test/mailers/#{matches[1]}_test.rb"
    end
    watch(%r{^app/views/(.*)_mailer/.*$}) do |matches|
      "test/mailers/#{matches[1]}_mailer_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
    watch('app/controllers/relationships_controller.rb') do
      ['test/controllers/relationships_controller_test.rb',
       'test/integration/following_test.rb']
    end
  end

  # 指定のリソースに対応する統合テストを返す
  def integration_tests(resource = :all)
    if resource == :all
      Dir["test/integration/*"]
    else
      Dir["test/integration/#{resource}_*.rb"]
    end
  end

  # インターフェースが該当するすべてのテストを返す
  def interface_tests
    integration_tests << "test/controllers"
  end

  # 指定のリソースに対応するコントローラのテストを返す
  def controller_test(resource)
    "test/controllers/#{resource}_controller_test.rb"
  end

  # 指定のリソースに対応するすべてのテストを返す
  def resource_tests(resource)
    integration_tests(resource) << controller_test(resource)
  end

Guardの設定が完了したら、新しいターミナルを開き（図 2.1でやったようにRailsサーバーのターミナルと別にするのがポイントです）、次のコマンドを実行します。

$ bundle exec guard

リスト 3.46のルールは本チュートリアルに最適化したものなので、例えばコントローラのファイルを変更すると、Guardは即座にそれを検出して、そのコントローラの統合テストを自動実行します（図 3.13）。テストを変更ファイルだけではなく、フルで実行したい場合は、guard>プロンプトでReturnキーを押します。

図 3.13: クラウドIDEでGuardを使う

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

次の章に進む前に、ここまでの変更を忘れずにコミットしておきましょう。

$ git add -A
$ git commit -m "Complete advanced testing setup"