トップページを作成しよう
学習の目標
本章では、以下の内容を学習します。
- Rails のコントローラー作成方法を習得する
- ルーティングの基本概念と設定方法を理解する
- RSpec を使った基本的なテスト作成方法を学ぶ
- コントローラーテストの書き方と実行方法を習得する
- HTTP ステータスコードの役割と重要性を理解する
はじめに
ここまででテストやファイル生成といった、本格的にソースコードを変更するための準備を進めてきました。この章では、一旦仮のトップページを作成し、主にテストの基本的な書き方を学びましょう。
Home コントローラーの作成
まずは rails g controller コマンドを使って Home コントローラーと top アクションを作成します。コマンドは rails g controller コントローラー名 アクション名 という形式で実行します。
$ bin/rails g controller Home top create app/controllers/home_controller.rb route get "home/top" invoke tailwindcss create app/views/home create app/views/home/top.html.erb invoke rspec create spec/requests/home_spec.rb create spec/views/home create spec/views/home/top.html.tailwindcss_spec.rbこのコマンドを実行すると、Home コントローラーやビュー、テストなど、必要なファイルが自動的に生成されます。前章で config.generators の設定を変更したため、不要なファイル（CSS、JavaScript、ヘルパー）は生成されていないことが確認できます。
初期動作確認
Home コントローラーを作成したら、一旦トップ画面にアクセスして動作確認をしましょう。bin/dev コマンドで開発用サーバを起動します。
$ bin/dev11:30:30 web.1 | started with pid 4158211:30:30 css.1 | started with pid 4158311:30:33 web.1 | => Booting Puma11:30:33 web.1 | => Rails 8.0.1 application starting in development11:30:33 web.1 | => Run `bin/rails server --help` for more startup options11:30:34 web.1 | Puma starting in single mode...11:30:34 web.1 | * Puma version: 6.6.0 ("Return to Forever")11:30:34 web.1 | * Ruby version: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin21]11:30:34 web.1 | * Min threads: 311:30:34 web.1 | * Max threads: 311:30:34 web.1 | * Environment: development11:30:34 web.1 | * PID: 4158211:30:34 web.1 | * Listening on http://127.0.0.1:300011:30:34 web.1 | * Listening on http://[::1]:300011:30:34 web.1 | Use Ctrl-C to stop11:30:35 css.1 | ≈ tailwindcss v4.0.911:30:35 css.1 |11:30:35 css.1 | Done in 99msサーバが起動したら、ブラウザで http://127.0.0.1:3000/home/top にアクセスしましょう。
このように、「Home#top」という文字が表示されていれば成功です。TechLog は Tailwind CSS を導入しているため、デフォルトで生成されるビューにも Tailwind CSS のスタイルが適用されています。
動作確認ができたら、ここまでの変更をコミットしておきましょう。サーバーは起動したままなので、別のターミナルを開いてコミットを行います。VS Code で techlog-app フォルダを右クリックして、新しいターミナルを開いてください。
$ git add .$ git commit -m "Homeコントローラとtopアクションを作成"また、Rubocop の検査もかけておきましょう。Rubocop の指摘は書き方のお作法に関するものがほとんどなので、自動修正してしまって問題ありません。
$ bundle exec rubocop -a自動修正が完了したら、この段階で一旦コミットしておきます。
$ git add .$ git commit -m "Rubocop による指摘事項修正"ルーティングの変更
次に、トップページを表示するためのルーティングを変更します。現在は /home/top というパスで Home コントローラーの top アクションが実行されますが、このページをサイトのトップページとするために、ルーティングを変更しましょう。
config/routes.rb ファイルを以下のように修正します。既存の記述はすべて消して、以下のように書き換えてください。
Rails.application.routes.draw do root 'home#top'endこの設定により、/ というパス（ルートパス）にアクセスすると、Home コントローラーの top アクションが実行されるようになります。ブラウザで http://127.0.0.1:3000 にアクセスし、Home#top が表示されることを確認してください。
先ほどまでは /home/top にアクセスしていましたが、今回は / にアクセスするだけで同じ画面が表示されるようになりました。URL の末尾に何もつけないようなパスを「root」（ルート）と呼びます。ルートパスは、Webサイトのトップページや、特定のコンテンツを表示するページなどに使われることが多いです。
Home#top のテスト作成
ここからは Home コントローラーの top アクションに関するテストを準備します。まだモデルは用意されていないため、基本的な動作のテストのみになりますが、簡単なところから始めて少しずつテストの書き方に慣れていきましょう。
テストの変更（リファクタリング）
Home コントローラー作成時に、自動的に spec/requests/home_spec.rb というテストファイルが生成されています。このファイルを以下のように修正してください。
require 'rails_helper'
RSpec.describe 'Home', type: :request do describe 'GET /' do it 'HTTP ステータス 200 を返す' do get '/' expect(response).to have_http_status(200) end endendこのテストコードの各行の意味を詳しく見ていきましょう。
require 'rails_helper' # rails_helper で定義した設定を読み込む
RSpec.describe 'Home', type: :request do # テスト対象モジュールとテストの種類を指定 describe 'GET /' do # テストする機能に関する説明 it 'HTTP ステータス 200 を返す' do # どういう結果を期待しているか get '/' # 確認したい操作: / というパスに GET でリクエストを送る expect(response).to have_http_status(200) # 期待する確認結果 end endendこのテストの流れを簡単に説明すると次のようになります。
まず require 'rails_helper' で RSpec の設定を読み込みます。次に RSpec.describe でテスト対象のモジュールを指定し、describe でテストする機能に関する説明を書きます。it ブロックの中では、期待する結果を記述します。
テストの内容としては、ルートパス（/）にGETリクエストを送り、そのレスポンスの HTTP ステータスコードが 200（成功）であることを確認しています。これはユーザーがトップページにアクセスしたときに、正常にページが表示されることを確認するテストです。
リクエストのテストでは、ページの中身よりも、アクセス時（リクエストをサーバーに送った時）の挙動をテストしています。
テストの実行
テストが準備できたので、RSpec を実行してみましょう。（spec/views フォルダは丸ごと削除して構いません。）
$ bin/rspecRunning via Spring preloader in process 43405Home GET / HTTP ステータス 200 を返す
Finished in 0.08102 seconds (files took 0.23599 seconds to load)1 example, 0 failures上記のように、テスト結果画面には describe として書いた「テストする機能に関する説明」と、it として書いた「期待する結果」が出力されています。前章で --format documentation オプションを設定したおかげで、テスト結果が整形されて表示されるため、どのテストがどのような結果になったかが分かりやすくなっています。
変更のコミット
Home#top のテストを作成できたので、変更をコミットしておきましょう。今回はテストの内容をリファクタリング（より良い形に変更）したので、その旨をコミットメッセージに含めます。
$ git add .$ git commit -m "Home#topの実装・テストを追加"RSpec テストに関する補足
describe/context/it の使い分け
RSpec のテストでは、describe、context、it の各ブロックを適切に使い分けることで、テストの意図を明確に表現できます。
describe- テスト対象のクラス、メソッド、機能などを説明context- テストの前提条件や状況を説明it- 期待する具体的な結果を説明
これらを適切に使い分けることで、「どのような状況で、どのような動作を期待しているか」が明確になり、テストコードの可読性が向上します。
参考リンク：
RSpec マッチャ (matcher)
RSpec を使うメリットの一つとして、今回使用した have_http_status のような マッチャ と呼ばれる機能があります。マッチャを使わなければ response.status という形でレスポンスから HTTP ステータスコードを取り出す必要がありますが、マッチャを使うことでより簡潔に書くことができます。
RSpec には、さまざまな状況に対応した便利なマッチャが多数用意されています。すべてを覚える必要はありませんが、使用頻度の高いものだけでも知っておくと、テストを効率的に書けるようになります。
参考リンク：
HTTP ステータスコード
テストの中で確認している HTTP ステータスコード は、Web アプリケーション開発においては重要な概念です。HTTP ステータスコードは、Web サーバーからクライアントへのレスポンスの状態を示す3桁の数字です。主なステータスコードには以下のようなものがあります。
2xx (成功): リクエストが成功した
- 200 OK: リクエストが成功し、レスポンスが返された
- 201 Created: リソースの作成が成功した
3xx (リダイレクト): さらなるアクションが必要
- 301 Moved Permanently: リソースが永続的に移動した
- 302 Found: リソースが一時的に移動した
4xx (クライアントエラー): クライアント側に問題がある
- 404 Not Found: リソースが見つからない
- 403 Forbidden: アクセス権限がない
5xx (サーバーエラー): サーバー側に問題がある
- 500 Internal Server Error: サーバー内部でエラーが発生した
Web アプリケーションを開発する上で、適切な HTTP ステータスコードを返すことは、クライアントとサーバー間の明確なコミュニケーションのために重要です。
参考リンク：
まとめ
本章では、Rails プロジェクトにトップページを作成し、基本的なテストの書き方を学びました。具体的には以下の内容を習得しました。
rails g controllerコマンドを使ったコントローラーの作成方法- ルートパスの設定方法と意義
- RSpec を使ったコントローラーのテスト作成方法
- HTTP ステータスコードの確認方法
Basicプランでより詳しく学習
この先のコンテンツを読むにはBasicプラン以上が必要です。より詳細な解説、実践的なサンプルコード、演習問題にアクセスして学習を深めましょう。