今回達成すること
- テスト結果を見やすくするGemの導入と
- テストデータにSeedデータを投入する設定を行い
テスト環境を整えます。
またこの記事では、Rails6から導入された並列テストについての解説も行います。
GO 並列テストとは?
テスト結果を色付けして見やすくするGemの導入
現状のRailsテストは、結果が白黒で非常に見にくい状態です。
そこでテスト結果を色付けしてくれるGemを導入します。
minitest-reportersのインストール
test
グループを作成し、その中でminitest-reporters(ミニテストレポーターズ)
をインストールします。
これにより、テスト環境で使用するGemとしてRailsに認識されます。
api/Gemfile
...
# 追加
group :test do
# テスト結果色付け Doc: https://github.com/kern/minitest-reporters
gem 'minitest-reporters', '~> 1.1', '>= 1.1.11'
end
# ここまで
# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]
root $ docker-compose build api
Gemのインストールを確認しておきましょう。
root $ docker-compose run --rm api bundle info minitest-reporters
* minitest-reporters (1.4.2)
...
minitest-reportersのセットアップ
インストール後は
api/test/test_helper.rb
ENV['RAILS_ENV'] ||= 'test'
require_relative '../config/environment'
require 'rails/test_help'
# 追加
# gem 'minitest-reporters' setup
require "minitest/reporters"
Minitest::Reporters.use!
# ここまで
class ActiveSupport::TestCase
...
以上でminitest-reporters
が使えるようになりました。
テストが色付けできているか確認
ここまでの設定を確認して見ましょう。テストコマンドを実行します。
root $ docker-compose run --rm api rails t
うまく色付けされましたね。
テストデータをSeedデータに切り替える
テストデータとは、Railsのテスト内で使われるデータのことです。
Railsのデフォルトでは「fixture(フィクスチャ)」を使ってテストデータを生成します。
fixtureとは
fixtureとは、Railsが用意しているテストデータを生成するための方法です。
この方法を使う場合、テストデータはymlファイルで生成します。
users.ymlファイルサンプル
<% 1000.times do |n| %>
user_<%= n %>:
username: <%= "user#{n}" %>
email: <%= "user#{n}@example.com" %>
<% end %>
ymlファイルでRailsコードを書くには
ymlファイル内でRailsを実行するにはERB形式(Html内にRubyコードを書く方式)で書く必要があります。
あの<% %>
でコードを囲む方式です。
ただこの方法は書きにくいといったデメリットがあります。
今回のテストデータの生成方法
そこで今回は「fixture」を使わず、開発環境と同じSeedデータをテストデータとして使用します。
設定は簡単で
同時に「fixture」の読み込みは削除します。
api/test/test_helper.rb
...
class ActiveSupport::TestCase
# 追加
# プロセスが分岐した直後に呼び出し
parallelize_setup do |worker|
load "#{Rails.root}/db/seeds.rb"
end
# ここまで
parallelize(workers: :number_of_processors)
# 削除
# Setup all fixtures in test/fixtures/*.yml for all tests in alphabetical order.
# fixtures :all
end
-
parallelize_setup(パラレルライズセットアップ)
...並列テストで使用するメソッドです。
プロセス開始直後に実行したいアクションをブロック内に記述します。
並列テストとは?
Raisl6で新たに追加された機能で、複数のプロセスを分岐させテストの実行時間を短縮する機能のことです。
スレッド化のサポートもされていますが今回は触れません。
並列テストの有効化
並列テストはデフォルトで有効になっています。
有効無効の切り替えは下記コードで行います。
parallelize(workers: :number_of_processors)
workers: プロセス数
workers:
に渡す値がプロセスが分岐する数となります。
2以上の場合はプロセスが複数分岐するので並列テストが有効になります。
デフォルトの:number_of_processors
は使用しているマシン(Docker)のコア数が入ります。
Dockerのコア数確認
使用しているイメージのコア数を確認するにはコンテナに入って$ nproc
コマンドを実行します。
# apiコンテナに入る
root $ docker-compose run --rm api sh
# コア数確認
/app # nproc
2
# コンテナから抜ける
/app # exit
並列テストの無効化
並列テストを無効化する場合はworkers
に1以下の値を渡します。
プロセスが1つになるため並列テストが無効になります。
parallelize(workers: 1)
データベースの自動作成
workers
の値が2の状態で並列テストを実行すると、自動的にapp_test-0
とapp_test-1
という名のデータベースが作成されます。
# PostgreSQLに入る
root $ docker-compose exec -u postgres db psql
# データベース一覧を取得する
postgres=# \l
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------------+----------+----------+------------+------------+---------------------
app_development | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
app_test | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
app_test-0 | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
app_test-1 | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
...
# PostgreSQLから抜ける
postgres=# \q
並列テストが有効な状態でテストを実行すると、このapp_test-0
とapp_test-1
のデータベースが使用されます。
データベースへのデータ投入時期
app_test-0
とapp_test-1
はプロセスが分岐した後に参照されます。
そのため、プロセスが分岐した直後にテスト環境へSeedデータを投入しないと、テストデータベースに何も入っていないといった現象に陥ります。
よって今回はparallelize_setup
内でSeedデータの投入を行なっています。
parallelize_setup do |worker|
load "#{Rails.root}/db/seeds.rb"
end
(筆者はユーザーデータが取れず3時間はまりました。。。:dizzy_face: )
ここまでの変更を確認してみよう
テストは何も書いていませんが実行してみましょう。
root $ docker-compose run --rm api rails t
...
users...
users...
users = 10
users = 10
ユーザーSeedデータがテスト環境に投入されていますね。
2つのプロセスに分岐しているため2回の表示があるはずです。
コミットしとく
これでテスト環境が整いました。
コミットしておきましょう。
root $ cd api
api $ git commit -am "test_environment_setup"
api $ cd ..
root $
まとめ
今回は
- テスト結果を色付けする
minitest-reporters
の導入と - テストデータにSeedデータを投入し、
テスト環境を整えました。
また、Rails6から導入された並列テストについても学んでいきました。
このカテゴリーではユーザーモデルしか生成しないので、あまりテストの速さを体感できないかもしれませんが...。まあ速くなるに越したことはないですね。
さーて次回は?
ユーザーモデルのバリデーションテストを行います。
いよいよモデル開発も佳境へ!
GO!! ↓次の記事へ。