Rspecのテストのベストプラクティスがわからん

勉強まとめ記事です。最近Rspecよく書かせてもらっているのでRspec多めです。

会社のコードを世に出すのは良くないと思うので、抽象的な概念でご了承ください。

通常のテスト

descrive・・・テストの対象。クラスだったり、コントローラーのメソッドだったり。

context・・・特定の条件を書く。「〇〇のときは」。

it・・・期待動作。「〇〇になる」。日本語ならexampleで書いて、itは英語で書こうみたいな記事もあった。プロジェクトによって使い分けよう。

descrive 'テスト対象' do
  context '〇〇のときは' do
    it '〇〇になる' do
      expect(huga).to eq true
    end
  end
end

基本スタイル。

テストやってて迷うとき

Aの処理の中にBの処理が入っているとき、Bの処理をどう扱うべきか？

めっちゃ抽象的にかいたけど伝わるかな？

詳細に説明すると、

テスト対象→Aの処理。この中でのテストを実行したいのだが、途中でBの処理を挟まなければならない（Bの処理はなかなか複雑）。

このとき、「Bの処理を挟んでも処理が通るようにRspec側でデータを用意するべき」か「テスト用にモック作ってそれで済ましてしまう」かでめっちゃ悩む。

ケースによりけりだとは思うのだけど、上司と相談して今回のケースの場合は「テスト用にモック作ってそれで済ましてしまう」という話になった。

Aの処理がテスト対象なのだが、期待する動作（itの部分）がBの処理で行われている

このサブタイトルの場合皆さんどうするだろう。

400エラーが期待動作だとして、それを起こしているのが、先程の例で言うBの処理の中で起きているのだが、これも「テスト用にモック作ってそれで済ましてしまう」方法で解決した。

要するにBの処理まるまるモック化して処理行うまでもなく、Bの処理に来た時点で400エラーを起こすような実装をした。

ここではAの処理の振る舞いをテストしているわけだから（Bの処理をしたいわけではない）、これでも良いのかもしれないけど、なんとなく腹落ちしていない自分もいる。多分「Aの処理の振る舞い」がちゃんと理解できていないのだろう。ここは明日もう一度上司に聞いてみよう。

基本的にRspecの単体テストでは、メソッドならば、

どういった役割のメソッドなのか　＝　期待動作

になってくると思うのだが、その期待動作をモックで作ってテストをパスするのはどうなのだろう？

期待動作が 

Hello 

と出力したいテストだとするのにモックで puts 'Hello' と出力されるの作っておいて実際のコードに流し込んでテスト通してる感じ。

伝わるかなこれ。多分僕にしか伝わってないな。申し訳ないです。

テストって奥が深い。というか自分の中でまだ確立していない。明日もRspecで記事書いてそう。