ブラウザ内テキスト探索の高速化というテーマで改善を行いました。公開許可は頂いていますが、先方の希望で社名は伏せさせていただきます。 技術的には「再現性がある木構造のノード探索の条件の生成、その実行の高速化」という少しR&Dっぽいタスクでした。Playwright のコードを参考にしつつ、個別により速いパーツで置き換えていく、というもので非常に興味深いものでした。こういう仕事は楽しいので、いくらでも歓迎です。 今回は最初はドメイン理解に時間をあてて、その後十分にドメイン理解が進んだら計測しつつ改善する、という流れです。 以下、敬称略。 相談内容 ブラウザを自動操作する技術を開発している。技術的には一種のE2Eテストの応用技術で、サーバーに要素の探索条件と、その操作を登録する。 今回の相談では、その要素探索が重くなってしまうケースがあり、これを改善してほしい、という依頼。とくにテキストを条件に
Rails: システムテストのドライバをSeleniumからPlaywrightに差し替えたら安定した（翻訳）｜TechRacho by BPS株式会社
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Running Rails System Tests with Playwright instead of Selenium | justin․searls․co 原文公開日: 2024/06/18 原著者: Justin Searls -- Test Doubleの共同創業者です 日本語タイトルは内容に即したものにしました。 先週、DHHが「システムテストの導入は失敗だった」と宣言したとき、私の最初の心の声は「まあそうだろうね」でした。UIテストはもろいうえに、テスト件数がある程度以上になると、アプリが動作しているという確信をもたらしてくれるUIテストのありがたみよりも、UIテストをメンテナンスするコストの方が上回ってしまう可能性があります。 しかし、私の次なる心の声は「考えてみれば、Turboに強く依存した複雑なUIに対して
Github Actions上で動くPlaywrightを少しでも早くするために、ブラウザを毎回インストールする方法からDocker imageを使う方法に変更しました。 imageのバージョンはpackage.jsonに記載しているバージョンと同じものにします。 (色々あってライブラリのインストールとテスト実行は別々のジョブにしている) jobs: setup: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Cache node modules uses: actions/cache@v4 id: cache-node-modules with: path: node_modules key: node_modules-${{ hashFiles('yarn.l
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Playwrightを参考にブラウザ内テキスト検索を高速化する (事例紹介:サードパーティスクリプト提供会社)
PlaywrightのDocker imageとactions/cache - Qiita