RSpecのコードの書き方に関するQiita記事を書きました

お知らせ

Qiitaに「【アンチパターン】Arrange、Act、Assert（AAA）を意識できていないRSpecのコード例とその対処法」という」記事を書きました。

この記事はざっくりいうと、こんなRSpecのコードよりも、

describe 'キャンセル処理' do
  let(:user) { create :user }
  let(:reservation) {
    create :reservation,
      user: user,
      start_at: '2017-08-10 10:00'.in_time_zone
  }
  context '24時間前をすぎるとキャンセル料が発生する' do
    before do
      travel_to '2017-08-09 10:00'.in_time_zone
      reservation.cancel!
    end
    after { travel_back }
    let(:billing) { user.billings.first }

    it { expect(user.billings.count).to eq 1 }
    it { expect(billing.amount).to eq 500 }
  end
end

こんなコードの方がいいよね？というお話です。

describe 'キャンセル処理' do
  let(:user) { create :user }
  let(:reservation) {
    create :reservation,
      user: user,
      start_at: '2017-08-10 10:00'.in_time_zone
  }
  context '24時間前をすぎた場合' do
    before do
      travel_to '2017-08-09 10:00'.in_time_zone
    end
    after { travel_back }

    it 'キャンセルするとキャンセル料が発生する' do
      reservation.cancel!

      expect(user.billings.count).to eq 1

      billing = user.billings.first
      expect(billing.amount).to eq 500
    end
  end
end

「えっ、なんで？」というその理由はQiita記事の中に詳しく書いてあるので、そちらを参照してください！

qiita.com

最近の僕が書いてるテストコードの傾向

一時期は僕もletやbeforeやsubjectをあれこれ駆使して、DRYでカッコいいテストコードを書こうとしていました。
しかし、最近はそういったテストコードはやめて雑にコードを書くようにしています。

RSpecの機能を駆使しまくって書いたテストコードは書くのにも時間がかかるし、書いてからしばらく時間が経つと、ぱっと見てよくわからなくなるし、新しいテストコードを追加するときも「これ、どこに追加したらいいんだ・・・？？」と迷いがちになります。
なので結局、現在は「愚直にベタ書きして上から下に素直に読めるコードを書くのが一番いいや」という考えに至っています。

まあ、RSpecの機能を使った方が効率が明らかによくて可読性や保守性も落ちない、というときは、RSpecの機能も積極的に使うんですけどね。

そのあたりの話は以前書いたこちらのQiita記事に書いてあります。

qiita.com