Rspecの書き方を先輩たちに質問してみた話

コードリファクタリング中にテストを書こうと思ったのですが、ふと考えたら私のRspec冗長な気がする…！と思い、会社のSlackで先輩方にRspecの書き方を質問してみました。

ちなみに私が書いていたテストコードはこんな感じ。

describe 'hoge_method' do
  context 'hogeがふむふむのとき' do
    example 'trueになること' do
      ・・・略・・・
      expect(piyo.hoge_method).to eq true
    end
  end
end

冗長かも？と思ったのははexampleとexpectの内容がほぼ同じだからです。

先輩方からのアドバイス

先輩01さんの場合

context "valid" do
  context "hogehoge" do
   it do
   end
  end
end 

context "invalid" do
  context "mogemoge" do
   it do
   end
  end
end

同一context（テストデータ）で複数 it はしてないです。

先輩02さんの場合

describe … テスト対象
context … xxの時
it … こうなる

って感じですね。itはシンプルな時は省略したり

先輩03さんの場合

itに引数与えたら負け

↓のように期待値がexpect読むだけで一目瞭然になってればベスト
it { expect(true).to be true }

it 'trueになる' { expect(true).to be true }は冗長

※「理想なので追い求めすぎると逆にコストかかるので適度なところで線引が必要」とのことでした！

その他書き方に関する意見やアドバイス

letを上書きしない
テストデータを共通化しないで、各テストで全部書くのがいいとは一概には言えない
letはoverrideできるのが便利なとこで、contextに付随する条件を明示的にするのに便利
期待する結果がruby的なrueの値の場合、be以降を省略できる→expect(true).to be
be_truthyとか be_falsy とかもある
scala checkについては「テスト対象の関数への入力を(ある一定の境界内で)ランダムに生成して、境界値テストを自動化してバグを洗い出す手法」→テスト対象として興味ないデータをランダム値にするのとは意味が違う

結論

私が担当しているプロジェクトのテストコードは下記のように書くことにします。

describe 'hogehoge?' do
  context 'humuhumuが0のとき' do
    it { expect(piyo.hogehoge?("HOGE")).to be_truthy }
  end
end

letは使いこなせる気がしないので、使いたい！という場面が出るまでは使わない感じにします。

最後に

他にもこんな書き方があるよー！などのご意見やアドバイスがあればうかがいたいです！

先輩方、ありがとうございました🙏

まえとうしろ