テストの判断軸がようやく固まった

3日位連続でRspecの勉強まとめです！

昨日わからなかったところ（昨日の記事参照）を上司に相談したところ腹落ちできる答えが返ってきたのでまとめる。

僕はRspecで全部やろうとしていた

テストはRspecだけじゃない。実際に本番環境のような状態を作って実機で動かしてみて動作確認するテストだってある。あくまでRspecは手段の一つであって目的は「テストを行い抜け漏れを防ぐ」こと。

そのために世の中のプロダクトは様々な手法でテストを行いいろいろな観点を投入して抜け漏れを防ごうと躍起になっている。

昨日の話の続きになってしまうけど「Aの処理」の中に「Bの処理」があるのだとしたら「Aの処理」と「Bの処理」それぞれでテスト書いてあげるのが基本的な考え方。

その基本的な考え方をベースとしてプロジェクトによっては「Aの処理」の中の「Bの処理」もまとめて疎通確認してしまおうというのもある（らしい）。

モデルのそれぞれの単体テスト、コントローラーの単体テスト、それらを組み合わせた統合（総合？）テスト、実機での動作確認、これらをどう組み合わせるかはプロジェクトごとによりけり。

テストの判断軸がようやく固まった気がする。