これは何?
本番のアプリケーションを開発していくにあたり、
テストコードがかけないと自分の書いたコードが本当に問題ないのか確認が大変。
そこで、テストコード周りの情報をこのQiitaに集めて行く。
概要
伊藤先生の記事を読むことで概要を掴むことは問題なくできるかと思いますのでそちらを読んでください。
この記事で初心者ながらなるほどーと思ったのは二点。
- 「テストコードのテスト」が必要になるのは本末転倒。
- そのため、DRY意識しすぎず1画面に収まるように簡潔に書く。
- 「テストコードがない → リファクタリングできない→ コードレビューしても意味がない」
- 確かにって思いました。
他にもたくさんテストコードを書く上での参考になるチップスが入ってるので定期的に読みたいと思います。
Minitest
Railsがデフォルトでサポートしているテストフレームワークです。
システムが計画通りに動作していることを実際に確認するのはアサーション(assert)となります。
※assertの意味は「断言する」なので、この条件では「○○と断言する」と宣言したテストを書くような感じです。
▼ テスト実行コマンド
bundle exec rails test
=> 全てのテストを一括実行(システムテスト以外)
bundle exec rails test test/models/user.rb
=> 特定のファイルのみテスト実行
bundle exec rails test test/models/user.rb:6
=> 特定のファイルの特定の行だけテスト実行
bundle exec rails test test/models
=> 特定のディレクトリ内のファイルを全てテスト実行
bundle exec rails test -h
=> テスト実行できるオプションのヘルプ
bundle exec rails test:system
=> システムテストの実行
▼ テストファイルの中身
名称 | 役割 |
---|---|
controllers | コントローラ/ルーティング/ビュー用のテスト |
fixtures | テストデータを編成する |
helpers | ビューヘルパーのテスト |
integration | コントローラ同士のやりとり用のテスト |
mailers | メイラーのテスト |
models | モデル用のテスト |
system | UXに沿ったアプリのテストを行うシステムテスト |
application_system_test_case.rb | システムテストのデフォルト設定 |
test_helper.rb | テスティングのデフォルト設定 |
jobs | ジョブに関するテスト |
▼ テストデータベースについて
テストコマンドを実行するタイミングで、最新のスキームに合わせてマイグレーションされます。
また、テストデータベース内のデータに関してはフィクスチャでYAML形式で定義します。
▼ テストファイル作成
テスト用のコントローラーとモデルに関してはアプリケーション用のコントローラーとモデルに一対一で対応するため、
rails g
で生成したタイミングで作成されます。
bundle exec rails g system_test users
=> システムテスト用のファイル作成コマンド
bundle exec rails g integration_test user_flows
=> 統合テスト用のファイル作成コマンド
▼ setup/teardownメソッド
フィクスチャからデータを取得する関数などはDRYにした方が便利。
#各テストの実行前に呼ばれる
setup do
@user = User(:one)
end
#各テストの実行後に呼ばれる
teardown do
Rails.cache.clear
end
これ以上の内容はこちらを参考にしてもらえるとよりわかると思います。
RSpec
WIP