rspec-request_describerを整えた

https://github.com/r7kamura/rspec-request_describer を少し改善したという話です。

Rails Developers Meetup 2018 Day 4

先週末に Rails Developers Meetup 2018 Day 4 というイベントに参加してきました。その中のある発表で自分のつくった rspec-request_describer というライブラリが言及されており、意外と使われていることに驚き、久しぶりにこのライブラリを見直すことにしました。最初は「railsdm に参加してきたよ」という内容の記事を書こうかなと思っていたんですが、せっかくなら何かコードを書いてそれについての記事を書こうと思ったというのも、このライブラリを見直すことにしたきっかけのひとつです。

CHANGELOG

まずは CHANGELOG あたりから見直していこうと考えました。これについては以前も Patreon で触れたことがありますが、http://keepachangelog.com/ という CHANGELOG の書き方の指針を示している Web サイトがあり、この書き方に従うように全体的に表現方法を変更しました。Semantic versioning に従っていることを明示して、カテゴリごとに分類して、リリース日を付けてという作業になりました。

これまで、リポジトリによっては Pull Request で Contribute してくれた方の名前を CHANGELOG に載せたり載せなかったり揺れていましたが、載せない側に寄せることにしました。また、対応している Pull Request や Issue へのリンクも載せたり載せなかったりしていましたが、これも載せない側に寄せることにしました。この辺りを書かない側に寄せたのは、手軽に CHANGELOG を書けるようにしたいことと、より多くのケースをカバーできるようにするねらいが大きいです。

README

ひさしぶりに README を見ると、使い方などが少し分かりにくい印象を受けたので、このライブラリが RSpec のプラグインで、かつ rack-test や rspec-rails 向けに追加機能を提供するものであることを伝えるような内容に変更しました。また、紹介されているサンプルコードが古かったり一部動かなかったりしていたので、この辺りも見直すことにしました。

サンプルコードを眺めていて思ったのですが、現状このライブラリは JSON でリクエストを送ることを前提として実装されている感じなので、これは見直した方が良いかもしれないかもしれないなと思いました。確か rspec-rails だと、Content-Type を適切なものに設定すれば、それに応じて params に指定した値を適切な形にエンコードしてくれたような記憶があります。rack-test ではどうなのでしょうか。

あと別の問題として、actionpack 5 以降への runtime dependency を宣言しているので、非 Rails のことをあまり考えていないということや、rack-test のことをあまり考えていないのでもしかしたら params とかの形式を変えたあたりで動かなくなっている可能性を危惧しています。この辺り今後もう少し考えていこうと思っています。

RuboCop

コーディングスタイルが統一されていない印象を受けたので、RuboCop を導入することにしました。Metrics 系のものや Style/Documentation は従っても今のところあまり旨味が無さそうなので無効化しています。個人的には Metrics は無効化することが多いです。

CircleCI

RuboCop を導入したので、CI で検査することにしました。Ruby や Rails などのバージョンの組み合わせによるマトリクステストをやりたい場合は Travis CI を使うのが良いと思うのですが、今回はそこまでやる必要はないだろうと考え、慣れていて動かしやすい CircleCI を利用することにしました。

以前 TypeScript のプロジェクトの設定をしたときに、CircleCI の Docker コンテナで動かす設定も意外と使いやすいことを知ったので、今回も Docker コンテナで動かす設定にしてみました。それまでは VM マシン上で動かす設定をよく利用していました。CircleCI の提供している Ruby 用の Docker イメージを使うべきか、それとも DockerHub の Ruby イメージを使うべきか迷いましたが、CircleCI のドキュメントを読む限りでは基本的には公式のものが利用できるならそれを利用した方が良いというようなことが読み取れたので、今回は DockerHub のイメージを利用することにしました。Ruby のイメージには alpine 版や slim 版も提供されていますが、とりあえず基本のやつを利用して、処理時間等で困ったときにそれらの利用を検討しようと考えました。

Workflow を利用して RuboCop と RSpec を並列に動かすように設定してみたところ、Bundler のキャッシュ周りのコードがパターン化できてかつ冗長に感じられたので、Circle CI の Orb の機能を利用して共通化してもいいなと思っています。Orb を初めて紹介されたときは、実際はジョブごとに処理の内容が全く異なってくるのでこういうものは共通化できないのではないかという印象を受けていましたが、実際に CircleCI を設定してみるとボイラープレート的なコードが多く、Orb の必要性を感じました。しかし CircleCI では有料プランを利用していると Docker のレイヤーキャッシュが有効化されるため、自前でキャッシュを操作する必要はなくなり、課金具合によって必要性の変わる Orb というのはどうなんだ、というところで思考が止まっています。

RSpec

これまでテストが書かれていなかったので、この機会に追加しておくことにしました。RSpec のプラグインなので、かなりメタ的なことをしないと上手くテストが書けないのではないかと思っていましたが、普通にそのプラグインを利用するようなテストケースを自分で書いて動かば良いだけでした。

rack-test や rspec-rails で本当に上手く動くか確かめるには、テスト用の Rails アプリを用意して動かす必要がありそうで、ちょっと面倒だなと思っています。そういえばこの文章をいま書いているときに思い付いたんですが、https://github.com/r7kamura/rails_kwargs_testing を書いたときに Rails アプリを用意せずに ActionDispatch で適当に Controller と Router だけ用意してテストするというようなコードを書いたので、もしかしたら同じ仕組みで簡単にテストが書けるかもしれません。あとで試してみようと思います。

おわり

https://github.com/r7kamura/rspec-request_describer を少し改善したという話でした。