#対象読者
- テストコードを書いたことがない。（わたし）
- ブラウザをポチポチする~~クソつまら..~~テストしかしたことがない人。（わたし）
- ※ あとがき...テストの種類と基本文法を書いていたらボリューミーになってきたので実際に書いたコードは別の記事で載せます。
#まずテストの種類
現時点では「こういうのがあるんだー」程度の理解です。
#E2E(システム)テストとは
End to Endの略。コードからブラウザを操作して意図したとおりに表示、操作、画面遷移など出来るかをテストする
#テストコードを書くのは億劫である？
今回テストコードを書いてみて、自分の意図した通りに動いたらなかなか気持ちよかった。。。それに、テストコードを書き自動テストを実行すると良いことがある。
良いこと
- バージョンアップ時に既存機能が正しく動作しているかを素早く確認できる。（レガシーな現場では全機能をポチポチさせられてるSESの人もいるんです...良いか悪いかは置いといて...）
- 仕様を記述したドキュメントとしても機能する（設計書が整備されていない現場は多いです。）
- リグレッションテストが速攻で終わるので結局は開発効率を上げてくれる
参考書籍
#使用するテスト用ライブラリ
- RSpec...BDD（Behaviour-Driven Development)：振舞い開発駆動用テスティングフレームワーク
- Capybara...E2E（End-to-End)テスト用フレームワーク
- FactoryBot(テストデータ作成gem）
- selenium-webdriver(ブラウザを操作してくれるgem)
- chromedriver-helper(chromeを動かすのに必要)
- testのところに書くんですねー
group :development, :test do
gem 'factory_bot_rails','~> 4.11'
#省略
group :test do
gem 'capybara', '>= 2.15'
#省略
gem 'selenium-webdriver'
gem 'chromedriver-helper'
gem 'rspec-rails', '~> 3.7'
RSpecの基本形（用語と構造）
-
テストケースを整理・分類する
- describe...テストの対象機能の説明文
- context...条件の説明文
-
テストコードを実行する
- it...アウトプットを記述
- expect...（エクスペクテーション）期待される処理を記述する
describe '仕様を記述する対象' , type: [Specの種類] do
context [状況・状態の条件] do
before do
[事前条件]
end
it '仕様の内容（期待の概要' do
[期待する動作の処理]
end
end
describe '計算' do
it '1 + 1 は 2 になること' do
expect(1 + 1).to eq 2
end
end
##具体例
このようにdescribeとitが仕様として残る。
it(example)をネストして書くこともできる
describe '計算' do
it '1 + 1 は 2 になること' do
expect(1 + 1).to eq 2
end
it '2 - 1 は 1 になること' do
expect(2 - 1).to eq 1
end
end
・1つのit(example)の中にexpectを設置することもできる。ただし、expectがエラーになった時にテスト失敗で落ちてしまうので基本は1つのexapleに1つのexpectとする。
describe '計算' do
it '四則演算をする' do
expect(1 + 1).to eq 2
expect(2 - 1).to eq 1
expect(5 * 5).to eq 25
expect(40 / 5).to eq 8
end
end
###その他の文法
- before
- 前提条件を処理する際にdescribe内に記述。itが実行されるたびに新たに実行される。
- 次のitが実行されるまでにデータベースの状態は元に戻されるため、あるテストケースで行った処理のせいで別のテストケースが影響を受けることはない。
###今回は一旦ここまで、随時更新予定。次は
FactoryBotでテストデータを作成できるように準備するを書けたらいいな。