俺のRSpec死闘記_describeとitとexpect #初心者

前回のお話

今回は基本の基本describeとexpectと闘います。

まずうまいことinstallされていれば、Rspecのテストコードはプロジェクトルート直下にspecディレクトリができているはず。
そこにapp配下と同じ感じのディレクトリ構造があるので、書きたいクラスのテストクラスを同じ階層におきましょう。

今回は、app/models/baku.rbというmodelクラスのテストをspec/models/baku_spec.rbとして、進めます。

Rspecの基本構造

Rspecのコードは大体こんな感じ。今回はすげー最小限で。
今後どんどんカッコ良くしていく。

baku_spec.rb

require 'rails_helper'

describe Baku do
  baku = Baku.create(name:"Baku",sex:"Man")

  it "インスタンスが無事に生成されること"　do
    expect(baku).to be valid
  end

  it "Bakuが表示されること"　do
    expect(baku.name).to eq "Baku"
  end
end

1行目のrequire 'rails-helper'はお約束。

describeブロック

テストの一番外枠って位置づけ。
Bakuモデルのテストするよ！っていう感じ。この中にBakuモデルに必要なテストを書いていく。

it ブロック

さて、describeでBakuモデルのテストを行うことはわかったので、どんなテストをするのか書いていく。
ここでは、Bakuモデルの「インスタンスが無事に生成されること」とBakuの「nameフィールドが表示されること」の２ケースを書いています。
「○○な場合、XXであること」
テストケースって突き詰めるとこれですよね。まあ単純化すると。
ここの、XXであることをitブロックに書くイメージ。（今回は○○であることのコードは書いてません。次回登場予定）

expect

expectとは

主な意味予期する、(…を)(当然のこととして)期待する、待つ、(…が)(…に)来るものと予期する、(…の)期待を寄せ>る、つもりである、(…が)期待する、望む。要求する、思う

英語の意味通り、期待値を書くためのメソッドです。実際にXXであることを比較するために使います。
単純に、ここに記載した内容がOKだったらテストがパスし、NGだったらターミナルが真っ赤に染まります。

例えば、

baku_spec.rb

describe Baku do
  baku = Baku.create(name:"Baku",sex:"Man")

  it "インスタンスが無事に生成されること"　do
    expect(baku).to be valid
  end

ここで、bakuモデルに以下のような　validationが存在した場合

baku.rb

validates_presence_of :name,:sex,:tel

このままだとテストはパスしません。（create時にtelを渡していないので）

マッチャ

expect(XXXX).to be_validのbe_validはマッチャと呼ばれるものです。
これも名前の通り、マッチングするかどうかを決めるもので、他にもeqとかbe_falseとかがあります。（内容は見ての通り、イコールかfalseであるかという感じです）マッチャについては後の記事でまとめたいと思っている。自分のためにも。アチキ。

おしまいに

いかがでしたか。このくらいの超シンプルな構造から徐々にコードを増やしていくと、あのよくわからない複雑怪奇なRSpecのコードになるのですが、基本の構造から一つずつ追加していくと、なんとなく読めるようになった私は、お腹が空いたので、次回に続きます。