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だけかけばいいくらい
- factory bot
- traitとかつかうと後の人が幸せになる
- rspec-request_describerを使う
- request spec書くときはstatus codeをまず確認する
- 弊社内の基準に則っているか確認するためにもよさそう
- request specってどこまでtestみるといいんだっけ
- serializableの中で定義したfunctionとかあればそこが正しいかはチェックする
- ただのattributes はみない
- expectはまとめる
- わかる
- テストするときは複数件作れ
- すまん
- controller-specは避ける
- controller specはdeprecated
- system-spec書かない
- まぁカロリー高いしね
- 宣言の有無をテストしない
- 悪い例で書かれているmatcherはこれだけど。。。http://matchers.shoulda.io/docs/v4.3.0/Shoulda/Matchers/ActiveModel.html#validate_presence_of-instance_method
ネクストアクション
弊社内
- ステータスコード、どういうケース何にする?
- Railsガイト読む
- 最適なテスト勉強会
r7kamuraさんに聞く
- subjectの使い方のススメを聞く