こんにちは。H2開発グループのsaito-siteです。
今回は5/11(木)～5/13(土)の3日間開催された、Ruby Kaigi 2023 にオンラインで参加したのでそのレポートを書いていきます。
私は今回が初めてのRuby Kaigiだったのですが、参加してみた感想としては、、難しい！！Rubyの基本的な部分は把握している前提で進んでいくので、ついていくので精一杯でした、、
さて、3日間でRubyにまつわるいろいろなセッションがありましたが、その中で私はThe Resurrection of the Fast Parallel Test Runnerというセッションで話された、「テストの高速化」について自分なりにまとめてみます。

どうやってテストを高速化するか

Rubyでなにかしらソースコードを書いた際は、同時にminitestやrspecでテストコードも書くのが常だと思います。
プロジェクトが進むにつれてソースコードも多くなると、当然それに比例する形でテストコードも増えていき、テストを回す時間も増えていきます。
対応策としてはそれぞれのテストが完了するまでの時間を調べて、遅いものから早くすることなどがありますが、こういった対応はコストがかかって大変です。
楽に早くするにはお金をかけてサーバーを強化して並列テストをするのが良い、という話でした。
どちらも金銭的なコストがかかることには変わりがないのですが、前者の場合はテストコードをより早くできるような技術を持ったエンジニアを探す、といった時間的なコストもかかるため、サーバー強化をしてしまった方が楽だよという話だと理解しています。

rspecで高速化する際に使用するgem

minitestには並列テストの機能が備わっているのですが、rspecにはないのでgemを入れる必要があります。
rspecで並列テストをする際のgemとして紹介されたのが、parallel_testsとtest-queueという2つのgem。
pararellel_testsの方はテストを事前に分割して回す方式になっています。
ただこれには弱点があり、事前に分割してしまうので、遅いテストがあるとそれに引っ張られて全体が遅くなってしまうことがあります。(下の図の例でいうとテストの個数はA、Bどちらとも5個ですが、Bは時間のかかるテストが含まれているため、結局すべて回すのに9分かかってしまいます。)

それに対し、test-queueの方は事前分割ではなく、空いてるキューにテストを割り当てていくので無駄な時間が少ないという利点があります。

確かにこうして見てみるとtest-queueの方がテストの高速化が見込めそう。

まとめ

記事冒頭でもお話しさせていただきましたが、私にとってはかなり難しい内容の話が多くついていくので精一杯のセッションがほとんどでした。まずは前提となるRubyの知識をもっと付けてよりセッションの内容を理解できるようにしたいなと思いました。