Rspec 行ってみて大切だと思った点がある話
プログラミングを本格的にスタートして3ヶ月目に入りましたさかもとです。
今回はRspecを初めて行ってみて大切だと思った点！という話をアウトプットしようと思います。
1. FactoryBotのDateの書き方
FactoryBotでtaskモデルを定義した際にdeadlineというカラムがありました。
このカラムは" 0000/00/00/ 00:00 "のように日時を表示するカラムだったのですが私は Deadline { " 1998/01/01 " } このように書きました。
こうすると時間は00:00で定義されるのでtaskモデルが定義されます。
しかし、実際にはこの書き方はよくありません。
日時を固定するような定義の仕方は汎用性がないからです。
そこで使われるのは " 1.week.from_now "
こうすることで現在の日時が自動で適用されるので汎用性も高く便利！
2. sequenceの書き方
titleカラムに対してユニークな値を定義しなければならないという問題で私は" sequence (:title) { |n| "書類作成#{n}" } と記述しました。
これはtitleカラムに対して1つ目のモデルが定義されたらn = 1となり発効されるtitleは 「 title 1 」となります。
こうすることで絶対にかぶることのないタイトルカラムを実装することができます。
この書き方は決して間違えではありません。しかしもっと簡潔に書くこともできます。
" sequence { :title " title_1" } "
もう圧倒的簡潔。titleカラムに1つ目の定義ではtitle_1が入り２回目からは title_2 と入ります。
このほうがDRYなかきかたなので頭の片隅に入れておきましょう。
3. テストの書き方
Rspecのテストで大切なことはわかりやすく！もれなく！これに尽きると思います。
以下の例はどうでしょう
ex) it 'titleがなければ無効の状態であること" do
title = FactryBot.build(:task, title: nil )
title.valid?
expect(title.errors[:title]).to include("can't be blank")
今回は内容ではなく書き方に触れたいと思います
１. 変数は何を入れるものなのかがわかりやすいように書く。titleよりstatus_without_titleのほうが他の方はみたときにわかりやすい。
2 . title.valid?より expect(task_without_title).to be_invalidの方が良い。期待される値に対してどう処理するかが明確。be_invalidは無効。
3 . includeは配列と一緒に使われ、今回の場合エラーメッセージの中にある"can't be blank"が含まれているかを検証するマッチャです。使い方としては決して間違ってはいないかと思いますが今回の場合は eq でも問題ないということだけ念頭に置いておいてください。
