RubyKaigi 2023 に登壇しました。現地での登壇は3年ぶりです。
当日の発表スライドは以下です。スライドのコード中に出てくる ennd なんかは typo ではなく、松田さんのスライドテクニックで、end がネストしている場合、ネスト分 ennnndとしてコードを圧縮しています。
また例年 yahonda さんに英文レビューをしてもらっていたところ、今回は勤務先の事業部でメンバー全員 ChatGPT Plus がサポートされている流れで、GPT 4 を使ったレビューをベースにしたあたり時代背景としてのひとつの変化かもしれません。
スライド 100 枚を 30 分で話す競技にしてしまったのですが、いま流行りの『タイパ』は良かったかもしれません (通訳さんありがとうございました) 。
本編
すごくざっと話すと、「並列テストランナーとは何か？」から「並列テストランナーの種類」、「並列テストランナーの現在と今後」といった構成で作っています。
とりわけ「並列テストランナーの種類」について、現状で Ruby で実装されているメジャーどころの並列テストランナーのそれぞれの概略と、設計のポイントをまとめておきました。本編で話したのですが、並列テストランナーの機構自体を RSpec などのテスティングフレームワーク自体でサポートできると良いのではというひとつの考えが自分の中であり、そういったコントリビューションを各テスティングフレームワークにしていこうという人がいれば、そのヒントになると良いなあと思っています。
とっかかりとしては本編で話した Minitest と Rails 関係は何らかのヒントになるかもしれません。
そんな感じで、来年の RubyKaigi に登壇に向けてオープンなコードを書くことに目覚める人が増えるきっかけになるといいなあというのが、表紙のサブタイトル "The Force Awakens" に込めたもの。事前打ち合わせで通訳さんから聞かれたものですが、まあ、さすがに読み取れるものではないのでここでの補足としておきます。
プロダクトとしての test-queue
test-queue 自体が様々なテスティングフレームワークの各バージョンをサポートしているのですが、あまりに古い RSpec 2 と Minitest 4 はドロップしたいなあと思っていたところで、会場でアンケートを取ることにしていました。結果として会期中にリリースしたのが、The RubyKaigi 2023 Edition となる test-queue 0.9.0 です。
0.8.0 の機能はそのままで、新しい Ruby とその周辺環境で使う分には問題がないと思うので、ご活用ください。test-queue 自体は今回でひと区切りつけることができたと思うので、しばらく大きな非互換的な変化はないんじゃないかなと思います。
スローテストは設計改善へのヒント説
本編中で話した仮説です。テストスイートについて、ワーカーが処理する時間が短ければ短いだけ、ワーカーがロックする時間は短いです。つまりテストスイートが速く完了すればするだけ、ワーカー間全体としてスループットが上がるはず。モデル単位でいえばテストスイートとプロダクトコードは大体 1 対 1 の関係なので、スローテストのテストスイートはそもそも Fat モデルだったりするのではというのが起点。E2E テストも適切に分割されていると、理論的には全体のスループット向上に影響する気がします。このあたりのヒントは『プログラマーのための CPU 入門』に書かれているスーパースカラ、スーパーパイプラインからアイデアを触発されたものです。
本編で直接の言及をしていませんし、本発表とは直接的な繋がりはないものの、この書籍からはコンピュータの仕組みという観点からマルチコアを活かした並列での高速化へのヒントを得られるかもしれないので、こちらで言及をしておきます。
その後の会話やフィードバック
その後の会期中に自分の発表への会話で印象に残ったものです。
- hirocaster さんからは、test-queue のワーカーを数百単位で稼働させて事例を聞けたのは面白かったです。ビルドの足回りだと AWS CodeBuild の 72 Cores がなかなかの量だと思っていたところ、自前で用意しての大型のビルド環境構築は印象的な事例でした。彼からも RSpec 2 はドロップして良さそうという声を聞けたのはちょっとした後押しでした。
- moro さんは熟練の Rails エンジニア、かつ Cucumber の書籍も書いていたこともあり、test-queue の Cucumber が新しいバージョンで動かない点で困りそうなことはないか聞いてみたところ、いまは Cucumber は使っていないということで、そちらはまあ急がなくて良いかなというのが私個人のメンテナーとしての現状です。そんな感じで UA 起点での E2E テストでは RDBMS に限らず、chromedriver なども並列分起動してマシンリソース使いますね的な話をしていました。そして、E2E はスローテストになりがちなので、ゴールデンパスを中心とするような E2E と、細かな条件分岐とするユニットテスト、それぞれの領域でテストを使い分けるの大事だねみたいな話をしていました。
- ledsun さんとは、各テスティングフレームワークに並列テストランナーを持つのであれば、それは独自インタフェースではなく、Web サーバー/フレームワークにおける Rack のような中間層のインタフェースを設けると良いのではという話をしました。いやあ、たしかにそれができると良さそう。一方で各テスティングフレームワークにその中間層を売り込みに行く作戦などは立てておけると良いかも？現状の Minitest / Rails あたりがヒントになるのかなあ。少なくとも RubyKaigi 2024 までの間に自分が手を出すことはない気がするので、興味のある人がいればアイデアとしてどうぞ！
- m_seki さんからは、「そもそもそんなにテストするのが良くないんじゃない？」みたいな話があり、さすが本質を突いてもらいました。テスティングとチェッキングは違うよというものだと思うのですが、たしかに何年も失敗していないテストを毎回実行させる必要はないんですよねえ。このあたり onk なんかとも、毎回のビルドで実行するテストと、1日1回だけビルドするテストは分けて良いかもというような話をしました (つまり常のフルビルドではなくてよいのでは) 。それと何年も落ちていないテスト、もう落ちることないかもですが、ビジネスの先によってアプリケーションの変更がどうなるか予測不可能な部分もあって、 (ものにもよるものの) なかなか捨てるに踏み切れないんですよねえ。
発表後にこういったいろいろな会話をできるのは、オンラインの間はできなかったことで良かったです。特に会場のリアクションは現地で話す際の醍醐味だったので、test-queue 0.9.0 はそういった意味でも "The RubyKaigi 2023 Edition" としてメモリアルカットしています。
最後に、通訳さん、オンライン配信業者さん、そして 1,200 人もの国際大規模イベントを運営されたスタッフのみなさんありがとうございました！
RubyKaigi 2024 に向けてハックを続けましょう！
