Chapter 08

2-5. トップページ作成

Masuyama
Masuyama
2022.10.15に更新

トップページ作成

ここまででテストやファイル生成といった、本格的にソースコードを変更するための準備を進めてきました。

今回は一旦仮のトップページを作成し、主にテストの基本的な書き方をみていきましょう。

Home コントローラー作成

まずは rails g controller を使って Home コントローラー、および top アクションを作成してあげます。
rails g controller コントローラー名 アクション名という形式でコマンドを実行します。

$ bundle exec 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

以前、生成ファイルの設定を行なっていたおかげでアセットファイル、ヘルパーファイルは生成されていませんね。
view のテストファイルも生成されていないことが分かります。

また、invoke tailwindcssというように Tailwind CSS に関する変更が行われていることに注意しておきましょう。
詳細についてはこの後のカリキュラムで解説していきます。

初期動作確認

Home コントローラーを作成した段階で、一旦トップ画面にアクセスしてみましょう。

rails s コマンドで開発用サーバを起動します。

$ bundle exec rails s
=> Booting Puma
=> Rails 7.0.3 application starting in development
=> Run `bin/rails server --help` for more startup options
Puma starting in single mode...
* Puma version: 5.6.4 (ruby 3.0.4-p208) ("Birdie's Version")
*  Min threads: 5
*  Max threads: 5
*  Environment: development
*          PID: 40714
* Listening on http://127.0.0.1:3000
* Listening on http://[::1]:3000
Use Ctrl-C to stop

問題なく起動することを確認したら、ブラウザで http://127.0.0.1:3000/home/topにアクセスしましょう。

<img width="600" alt="スクリーンショット 2022-06-18 23 24 25" src="https://user-images.githubusercontent.com/68495563/174442780-bf9b9522-cd05-4ad8-8eb5-fe79171eff0e.png">

このように、Home#top の view が表示されていれば OK です。
(この時、既に Tailwind CSS を使った見た目になっていますが、それについては後ほど)

ひとまず動作確認は済んだので、ここまでで一旦コミットしておきます。

$ git add .
$ git commit -m "Homeコントローラとtopアクションを作成"

また、Rubocop の検査もかけておきましょう。

$ bundle exec rubocop
Inspecting 14 files
............C.

Offenses:

...
spec/requests/home_spec.rb:10:1: C: [Correctable] Layout/EmptyLinesAroundBlockBody: Extra empty line detected at block body end.

14 files inspected, 5 offenses detected, 5 offenses autocorrectable

詳細は割愛しますが、すべてスタイルやレイアウトに関する内容であり、動作には影響ないことを確認できたので自動修正します。

$ bundle exec rubocop -a

自動修正が完了したら、この段階で一旦コミットしておきましょう。

$ git add .
$ git commit -m "Rubocop による指摘事項修正(Lint)"

ルーティングの変更

現在は '/home/top' というパスで Home#top の view を表示することになりますが、
一旦、このページをトップページとするためにルーティングを変更しましょう。

config/routes.rb を以下のように修正します。

config/routes.rb

Rails.application.routes.draw do
  root 'home#top'
end

これで / というパスが Home#top 画面を表示するためのパスになります。

ブラウザで今度は http://127.0.0.1:3000にアクセスし、Home#top が表示されることを確認してください。

image

Home#top のテスト作成

ここからは Home コントローラの top アクションに関するテストを準備します。

まだモデルは用意されていないため、基本的な動作のテストのみとはなりますが、簡単なところから初めて少しずつ慣れていきましょう。

テストの変更(リファクタ)

Home#top 作成時、自動生成されたテストファイルである spec/requests/home_spec.rbというファイルが生成されていたはずです。
このファイルを、以下のように修正してください。

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
  end
end

習生後テストのそれぞれの行の意味について、以下の通りコメントで説明をつけましたので確認してください。

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
  end
end

(describe や it については後述の宿題欄にて説明)

request のテストなので、ページの中身よりもとにかくアクセス時(リクエストをサーバに投げた時)の挙動をテストしています。

テスト実行

さて、これで一つテストが追加できたので RSpec を走らせてみましょう。

$ bin/rspec
DEBUGGER[spring app | techlog-app | started 33 mins ago | test mode#42184]: Attaching after process 40675 fork to child process 42184
Running via Spring preloader in process 42184

Home
  GET /
    HTTP ステータス 200 を返す

Finished in 0.12033 seconds (files took 0.33231 seconds to load)
1 example, 0 failures

上記のように、テストの結果画面では describe として書いた「テストする機能に関する説明」と、it として書いた「期待する結果」が出力されていますね。
このように、どのテストがどうなったか?は (--format documentation オプションのおかげで) 整形されて出力されるので、コケているテストがあれば詳細を確認しましょう。

変更をコミット

ひとまず、Home#top のテストを作成できたのでコミットしておきます。
今回はテストの中身をリファクタリング(より良い形に変更)したので、その旨をコミットメッセージに含めておきます。

$ git add .
$ git commit -m "Home#top のテストをリファクタ"

宿題

describe/context/it の使い分け

RSpec のカリキュラムでの参考サイトを読んだ方は理解済みかもしれませんが、
RSpec のテストでは describe/context/it それぞれのグループを適切に使い分けることで、どのようなテストを書いてあるかがひと目で分かるようになります。

まだ読んでいない方や、一度読んだけどボリュームが多いために忘れてしまった方は、参考サイトの以下の項目だけでも読んでおきましょう。

RSpec マッチャ(matcher)

RSpec を使うメリットの一つとして、今回出てきた have_http_statusのような マッチャ という機能があります。
マッチャを使わなければ response.statusという形でレスポンスから HTTP ステータスコードを取り出さないといけないのですが、マッチャを使ったことでより完結に書くことができました。

このように、RSpec には便利なマッチャがたくさん用意されています。

もちろん、すべてを把握しておく必要はないのですが、使用頻度の高いものだけでも覚えておくとテストを高速に書くことができるようになります。

HTTP ステータス

テストの中で、特定の URL にアクセスした時のレスポンスに含まれる HTTP ステータスコード を照合していました。
HTTP ステータスコードは Web アプリを開発する上では必須知識の一つですので、馴染みがない方はこの機会に概要だけでも掴んでおきましょう。