かれこれ１年半くらい、Ruby向けのブラウザオートメーションツールをいろいろ趣味で開発している。
特に中身はないが、これまでやってきたことを少しサマリ。
はじまりはRubykaigi2020
思えば、開発を始めた動機は非常に不純で、「Rubykaigi 2020になんでもいいから出てみよう」だった。悪く言えば、ただ目立ちたいだけ。Puppeteerはなんとなく好きで触ってたので、「Rubyに移植したらなんかすごいんじゃね？」くらいの気持ちで実装を初めて、手応えがあればRubykaigi2020のCFPを出そうとしていた。
ところが、そうは簡単にいかなくて、WebSocketとasync/awaitで完全に手詰まりとなる。
それでもconcurrent-rubyとお友達になり歩み直して、最初のリリースは2020/04/05だった。全然CFPに間に合っていない。
puppeteer-rubyと歩んだ9ヶ月
それでも、作っているものにだんだんと意味を感じ始めたので、少しずつpuppeteer-rubyの品質を高めていき、まずはSEO目的で少しブログ記事を書いた。
この頃は、たしかまだアーリーアダプター的なユーザは誰もいない。とはいえ、SeleniumよりもFerrumよりも（安定性という観点では）有利な確信はあったので、どんどん広めていくことにした。
初めての登壇: てすらぼミートアップ#2
まずは自動テストの集まりがあったので、そこで登壇させてもらった。これがおそらくエンジニアとしての人生初登壇。
第13回フクオカRuby大賞
思ったよりも共感をいただけた。ここで一気に調子をつける。
Playwrightに浮気を始めた
フクオカRuby大賞の実装をしているときに、どうしてもPlaywrightが気になったので、そのRuby版をPoCしたのが始まり。
- ピュアRuby Implementationなpuppeteer-rubyと比較すると、PlaywrightはRuby"クライアント"でしかなく、サーバーサイドはNode.jsで動いている。つまり、Seleniumと同様にRuby以外のものをセットアップする必要があり、導入がそこまで簡単ではない。
- Playwrightは1ヶ月に1回ペースで破壊的変更を含むアップデートが次々される。JSユーザが追従するだけでも大変なのに、Rubyクライアントを追従させて更にRubyクライアントのユーザに追従してもらうってなかなかに厳しいのでは？と感じた。
などの理由から、こっちはpuppeteer-rubyほど布教していなかった。
Playwrightへの注力
2021年になると、本家PuppeteerとPlaywrightの開発スピードの差が非常に顕著になってきた。そろそろPuppeteer一本で行くのはリスキーだと感じ始めた。
PlaywrightのRubyクライアントは、実はpuppeteer-rubyに比べてメンテナンスコストが少ない。サーバー側はとくに開発しなくても、クライアントインターフェース＋αだけ少し実装すれば、Playwrightの様々な機能が使える。そのため、開発のコスパがpuppeteer-rubyよりもだいぶいい。
問題は「Playwrightは自分で起動したブラウザしか自動操作できない」というところだったが、Capybaraドライバを作ってしまえばSystem Specから使えるし、それなりに需要はあるんじゃないかと想像した。
その方針をブログで宣言して、PlaywrightをRailsから使えるようにするための開発に注力を始めた。
Capybaraドライバの開発という苦行
PlaywrightをRailsから使うストーリに欠かせないのがCapybara。Playwrightベースのドライバをつくるため、Capybara DSLの書き方をなんとなく調べた。
そして、実際にCapybaraドライバを作った。
ブログの方にはcapybara-playwright-driverを最初から作ったように書いたが、実はフクオカRuby大賞の実装検証でcapybara-puppeteer-driverというのを作っていた。(完成はしていなかった)
DSLのバックエンドとして実装すべきメソッドが多く、何をどう実装すべきかは現状コピペプログラミングするしかないので、なかなかに面倒なことは想像していた、案の定、capybara-playwright-driverはだいぶ苦行だった。
あと、思ったよりもCapybaraは適当に作られている部分があることもわかった。
PlaywrightのRubyクライアントの布教
2021年4月頃、そろそろ playwright-ruby-clientが実使用に耐える品質になってきたかな？というのと、「テスト中の動画が撮れるので、画面の前でじっと見張って無くてもいいんだよ！」っていうインパクトが与えられそうな機能を移植も済んだ。
playwright.devをまねて、Docusaurus2でドキュメンテーションサイトも構築して、使ってもらうための準備も整えた。
playwright-ruby-client.vercel.app
（マイクロソフトはRubyに対して投資しない会社なので可能性はゼロだがw）playwright-ruby-clientがマイクロソフト配下になってもいいくらいのレベルでドキュメントは整備するように心がけた。
で、ここまでやったので、一旦フィードバックが欲しい。
不安定なE2Eテストと戦う選択肢として、playwright-ruby-clientがあるよ！というのを知ってもらおうと思い、銀座Rails#34で登壇させてもらった。
6/18(金)開催の銀座Rails#34、公募枠その2は @yi01imagination 「Railsのsystem specからPlaywrightを使う」に決まりました！
— 銀座Rails (@GinzaRails) 2021年5月31日
引き続き参加者募集中です。https://t.co/AYgOj0R89c
リモートなので、Twitterを通してくらいしか反応がみれないのだけど、「あ、こんなのあるんだ」くらいには認知されたんじゃないかなぁ。スライドの最後には書いてたんだけど、実運用でどのくらいの実力があるのか未知数なので、自動テスト運用してる人にはぜひPlaywright導入してほしいなw
そして、これから
JavaScript界隈ではCypressをはじめとして、優秀なE2Eテストフレームワークやブラウザ自動操作ライブラリがあるが、Rubyはというと現実的にはSeleniumしかないみたいな状況がずっと続いている。
ただ、IEがほぼ滅んだ今となってはRubyでもPlaywrightはSeleniumと同様に使っていけるはず。
いろいろOSS開発はしてきたが、そろそろSeleniumが唯一無二の選択肢みたいな状況には終止符うちに行きたいなと思っている。しばらくは、布教活動の比率を高めていこうと思う。
