2021年9月28日現場Rails Chapter5 テストをはじめよう

テストについて

動作を確認する方法として、一般的には以下の３パターンが挙げられます。
1. コンソールでメソッドを呼び出す
2. Webサーバ起動後に、ブラウザを操作して確認する
3. 自動テストを書く

この章では３つ目の「自動テストを書く」について深ぼっていきます。

テストを書くことのメリット

手動テストを自動テストに変更することで、さまざまなメリットを受けられます。

テスト全体にかかるコストの削減
変更をフットワーク軽く行えるようになる
環境のバージョンアップやリファクタリングの必須条件
仕様変更の影響の大きさを簡単に把握することができる
仕様を記述したドキュメントとしても機能する
仕様やインターフェイスを深く考えるきっかけとして役立つ
適切な粒度のコードになりやすい
確実性を高めることで開発効率をあげる

現場Railsではテストの重要性が丁寧に説明されています。

テスト用ライブラリ

RSpec

RubyにおけるBDD(Behaviour-Driven Development: 振武駆動開発)のためのテスティングフレームワークです。

本書でRSpecを扱う理由

テストが動く仕様書としても機能するということをより分かりやすく示せると判断した

RSpecは開発現場で広く利用されており、Railsと共にRSpecについて学べるということに十分に実用性がある

筆者たちはRSpecでの経験が多く、解説もしやすいためです。

TDD(テスト駆動開発)とは

【初心者向け】テスト駆動開発とRspecについて調べてみたが参考になりましたので、以下に引用します。

TDDとは以下の手順で開発を行っていく手法である
1.プロダクトコードを書く前にテストコードを書き、それが失敗することを確認する (レッド)
2.テストに成功するようにプロダクトコードを書く (グリーン)
3.プログラムの振る舞いを変えないように、プロダクトコードの重複などを整理する (リファクタリング) (最初に戻る)
またTDDには以下の原則がある
・テストに失敗しない限り、プロダクトコードを書いてはいけない。
・プロダクトコードはテストを通るように書く。
・テストは少しずつ書き進めていく。

BDD(振舞駆動開発)とは

現場Railsに詳しく書いてあるので、以下に引用します。

TDD(テスト駆動開発)から派生したのもので、動く仕様書でありテストでもあるBehaviour(振舞)をまず先に作り、その後でプロダクトコードを書いていくという開発手法のことを指します。

Capybara

E2Eテストが出来るテスト用フレームワークです。 Rails5.1からGemとしてデフォルトで同梱されており、MinitestやRSpecなどのテスティングライブラリと組み合わせて使います。
ブラウザ操作をシミュレーション出来ます。

UIテストとは

UIテストは、人間がチェックする時と同じ内容をテストします。
つまり、UIの操作・サーバーへのレスポンスとリクエスト・サーバーでのロジック処理と、全てのレイヤーを通したテストを行うことができるのがUIテストです。

画像引用

FactoryBot

テストデータの作成をサポートするGemで、ダミーデータを簡単に用意することが出来ます。また、Railsが標準で用意しているFixtureという仕組みを代替したGemでもあり、開発現場ではFactoryBotが広く利用されています。

テストの種類

主に使用されやすいのはシステムスペックとモデルスペックです。
システムスペックでブラウザの挙動を、モデルスペックでバリデーションのテストを主に行います。

System Specを書くための準備

RSpecのインストール

１. Gemfileにrspec-railsというGemを追加します。

gem 'rspec-rails'

２. bundleコマンド実行して、インストールします。

$ bundle

３. generateコマンドで、RSpecに必要なディレクトリや設定ファイルを作成します。

$ bin/rails g rspec:install

生成される主なファイル	ファイルの概要
spec/spec_helper.rb	RSpecの全体的な設定を書くためのファイル
spec/rails_helper.rb	Rails特有の設定を書くためのファイル

※RSpecはspecディレクトリに格納していくため、Railsのデフォルトのminitestのディレクトリであるtestディレクトリは不要になるので削除しておきましょう。

Capybaraの初期準備

Capybaraはデフォルトでインストール済みのため、spec_helper.rbで以下のように設定を行います。

# RSpecでCapybaraを扱うために、必要な機能を読み込む
require 'capybara/rspec'

# System Specを実行するドライバの設定
RSpec.configure do |config|
  config.before(:each, type: :system) do
    # ブラウザでHeadless Chromeを使うように設定したい→ドライバとしてselenium_chrome_headlessを設定
    driven_by :selenium_chrome_headless
  end
  
 # rspec-expectations config goes here. You can use an alternate

Headless Chromeについて、[Rails]雑にSystem TestでHeadless Chromeを使うが参考になりましたので、以下に引用します。

Rails 5.1の時点で、System Testは標準ではHeadless Chromeをサポートしていません。その為、Headless Chromeを使用するには、自分でHeadless Chrome用のオプションを指定する、または、独自のdriverを自分で準備する等の必要があります。

※ドライバとは、Capybaraを使ったテストにおいて、ブラウザ相当の機能を利用するために必要なプログラムのことです。
（参照）　ヘッドレスモードのchromeで実行する

調べた限り、現場Railsの書き方はRails5.1の書き方をしていて、Rails5.2からRails6.0においては以下のようにしてドライバを設定します。（パーフェクトRubyonRails参照）

# spec/rails_helper.rb
# ヘッドレスモード（画面を起動しないモード）でchromeで実行する
driven_by :selenium, using: :headless_chrome

FactoryBotのインストール

group :development, :test do
略)
  gem 'factory_bot_rails', '-> 4.11' # 本書ではバージョンを指定
end

以上でシステムスペックを書く準備が整いました。

spec_helper.rbとrails_helper.rbの違い

RSpec 3 時代の設定ファイル rails_helper.rb についてが参考になりましたので、以下に引用します。

rspec-rails のREADMEを読むと、これからは spec/rails_helper.rb に Rails 特有の設定を書き、spec/spec_helper.rbには RSpec の全体的な設定を書く、というようにお作法が変わるそうです。これによって、Railsを必要としないテストを書きやすくなるんだとか。