最近、 Rails の Controller spec を request spec に置き換えていっています。
ずっと古くから使われていたcontroller specのまま続けてきていたのを、今更ながらようやく移行し始めた。という状態です。
やりたいしやるべきだ。とタスクに積んでいたものが、ようやく実現されていっています。
なぜcontroller specからrequest specに置き換えるべきなのかという話は色々なところにあるので割愛するとして、
今いるチーム＋プロダクトで書き換えるべきだと思っていた理由は2つあって、
- controller spec だと get でも postでもなんとなく書いておけば動いてしまう。
- committee-rails を利用してスキーマ駆動開発のようなことをしたい。
というものでした。
前者はなんとなくspecファイルを見てこれはPOSTなんだな。と思ってAPIリクエストするコードを書いていたら、じつはPUTだったため動かなった。
というようなことを経験したから。
後者は、openapi schema から逸脱したレスポンスを返してないかをチェックできるのですが、request specを前提としていた(controller specでも動くけれど、完全ではなかった)から。
まだ移行途中なので、特に後者はまだまだ途中です。
移行していく途中で、一つ、メリットに感じることも出てきました。
プロジェクトでは bullet という、DBリクエストのN+1を検出するgemを利用していますが、
controller spec だとこれが動かず、request specだと動く。というのがあり、ローカルでrspecを走らせる過程で見逃していたN+1を発見できるようになった。ということがあります。
初期実装時は存在しなかったrelationについて、増えてもincludesに追加しないまま動いており、結果的にN+1になる。といったケースは意外と見落としがちですが、それが可視化されるよになったのはおおきなメリットかなと感じています。
railsを使う上では、可能な限り、rails wayに乗るべきだと思っているので、今後も少しずつ改善を続けていきたい。
