AppBrew Rails Best Practiceを読む会 その2

こちらの第2段 rspecから

目的

  • AppBrew Rails Best Practiceの内容を理解した上でmake-serverのコードを書いていけるようにする
  • 守れていない場合にレビューで指摘しやすくする
 

やり方

  • みんなで一緒に読んでいく
    • 1人1項目ずつ順番に読んでいく
  • 適宜深ぼったり議論したりする
    • ここの部分とか守れてないよねとか
    • こうするとよさそうとか
    •  

議事録

  • 不要なSQLが発行していないかみるってどうやって?
    • テストとか動かすと良いよ
  • 驚きの少ないコードとは?
    • Railsガイド嫁
  • statusコードってどうする?
    • 自分たちでルール決めれば世界的に正しい
  • methodにParamsにママ渡さんほうがええわよといいつつ、ActiveRecordのmethodでよく渡すものはあるがええんか?
    • ActiveRecordの実装として生えているParamsを受け取るやつ(newとかcreateとか)はそのまま使えばええよ
 
rspec編
  • ネストを深くしない
    • 完全木を作らないとなるとどれをテストするか選ばないといけないのむずくね?
    • これよむと完全解決するらしい https://www.amazon.co.jp/dp/4798130605
      • めちゃくちゃおすすめではないらしい
  • 文法規則
    • 例が厳しそう
    • context→どういうケースか、it→どうなるかくらいでいいんジャネという話
  • テストメッセージとコードを対応させる
    • subjectってどういう粒度?
      • 例えば job のテストは performまで含む?含まない?
    • narazaka: expectに突っ込むやつをsubjectにするくらいがちょうど良さそう
    • 呼び出し系はitの頭でsubjectだけかけばいいくらい
  • request spec書くときはstatus codeをまず確認する
    • 弊社内の基準に則っているか確認するためにもよさそう
    •  
 
  • request specってどこまでtestみるといいんだっけ
    • serializableの中で定義したfunctionとかあればそこが正しいかはチェックする
    • ただのattributes はみない
 
  • expectはまとめる
    • わかる
 
  • テストするときは複数件作れ
    • すまん
 
  • controller-specは避ける
    • controller specはdeprecated
 
  • system-spec書かない
    • まぁカロリー高いしね
    •  

ネクストアクション

弊社内
  • ステータスコード、どういうケース何にする?
  • Railsガイト読む
  • 最適なテスト勉強会
 
r7kamuraさんに聞く
  • subjectの使い方のススメを聞く