全部緑なのに、CIがなかなか終わらない
テストは全部通っている。赤い✕は1つもない。なのにCIパイプラインがなかなか終わらず、レビュー依頼のたびに数分待たされる。こういう状況、Playwrightでテストを書いていれば一度は経験があるのではないでしょうか。
失敗しているテストなら原因を追えば直せます。厄介なのは「通っているのに遅い」ケースです。エラーも出ないので、どこに時間を溶かしているのか手がかりがありません。私も似たような要件で、CIの実行時間をどうにか短縮したいという相談を受けたことがあります。この記事では、そんな「遅いけど通っている」テストの原因を、Playwrightの標準機能だけで突き止める方法を紹介します。
これまでは勘とconsole.timeで探すしかなかった
正直に言うと、私はこれまで「なんとなく重そうな処理の前後にconsole.timeを仕込んで、ログを目で追う」というやり方をしていました。
console.time('login');
await page.goto('/login');
await page.fill('#email', 'user@example.com');
await page.click('button[type=submit]');
console.timeEnd('login');
これでも一応の当たりは付けられるのですが、テストの数が増えるとログを仕込む箇所も増えて、結局どこが本当に重いのか埋もれてしまいます。CIの実行時間はダッシュボードで見えても、それは「全体で何分かかったか」でしかなく、「どのテストの、どの操作が」重いのかまでは教えてくれません。以前trace情報をCLIだけで追う記事を書きましたが、あれは「落ちたテストの原因」を追う話でした。今回の「遅いけど通っているテスト」は、そもそも追いかける対象を見つけるところからして違います。
Speedboardというタブがある
調べてみると、Playwrightの公式リリースノートにSpeedboardという機能が載っていました。HTMLレポーターの新しいタブで、実行したすべてのテストを遅い順に並べて表示してくれるというものです。バージョン1.57で追加されたと公式に書かれています。
これまでのHTMLレポートは、テストが通ったか落ちたかの一覧が中心でした。Speedboardはその発想を変えて、最初から「時間がかかっているテスト」を上位に並べてくれます。しかも視覚的に重み付けされているので、ぱっと見るだけで極端に遅いテストが目立つ作りになっているようです。これ、意外と使えます。
実際に開いてみる
使い方自体は難しくありません。playwright.config.tsでHTMLレポーターを有効にしていれば、追加の設定は不要です。まずは設定ファイルを確認してみましょう。
// playwright.config.ts
export default defineConfig({
reporter: [['html']],
});
テスト実行後、いつも通りレポートを開いてみましょう。
npx playwright test
npx playwright show-report
レポート画面を開くと、通常のpass/fail一覧に加えてSpeedboardのタブが増えています。ここをクリックすると通過したテストを実行時間の長い順に並べ替えたビューになります。以前CLIオプションを一通りまとめた記事を書いたのですが、そちらは実行の仕方を変えるオプションが中心でした。Speedboardはコマンドではなくレポートの見方の話なので、CLIオプションを覚えるより気軽に試せます。
クリックした先にタイムラインがある
Speedboardのランキングでテストを1つクリックすると、そのテストの中身がタイムラインとして表示されます。これは公式リリースノートによると、バージョン1.58でSpeedboardタブに追加された機能です。ただし公式ドキュメントには「マージされたレポートでタイムラインチャートが表示される」という趣旨の記載があり、複数のshard実行を1つにまとめたレポートが前提になっているようでした。単発のローカル実行だけで同じ見え方になるかは、私の手元では確認できていません（正直に言うと、ここは自信を持って断定できません）。
shardをマージしたレポートを見る手順自体は、以前触れたnpx playwright merge-reportsやtrace mergeの考え方と同じです。CIをshard分割している場合は、まず各shardのレポートをマージしてから開くことになります。
タイムラインの中で何が見えるか
複数の情報源を照らし合わせると、タイムラインは1本のテストの実行を左から右へ時系列で並べたグラフになっていて、フィクスチャのセットアップ・ページ遷移・要素の自動待機・ネットワーク通信・アサーション・後片付けといった区間ごとに色分けされているようです。区間の幅がそのまま所要時間を表すので、どこが太くなっているかを見るだけでボトルネックの見当が付きます。
ここで注意しておきたいのは、この区間の内訳の粒度(セットアップ/ナビゲーション/待機/ネットワーク/アサーション/後片付けという分け方)は、私が複数の二次情報を突き合わせて得た理解であり、公式リリースノートの一次情報としてそこまで詳細な区分が明記されているわけではないという点です。実際の画面でどこまで細かく区切られているかは、公式ドキュメントかご自身の手元のレポートで確認していただくのが確実です。
それでも「どの区間が太いか」という見方自体は素直に使えます。例えばナビゲーションの区間が異常に太ければ、待たなくていいページ遷移で無駄に待っている可能性があります。逆に自動待機の区間が太ければ、locatorの条件が緩すぎて要素が見つかるまで余計に粘っている可能性が高いです。
自分のプロジェクトで試してみた
手元のプロジェクトでも一度、CIの実行時間が気になっていたテストスイートに対して同じ手順を試してみました。Speedboardで上位に出てきたのは、想像していた「ログイン処理」ではなく、一覧画面を表示するだけの地味なテストでした。
タイムラインを開いてみると、太かったのはネットワークの区間です。一覧画面を開くたびに、テストとは関係のない外部の画像リソースの読み込みを毎回律儀に待っていました。これは私にとって完全に予想外で、正直「ここか」と声が出ました。
試しに、テスト側でその画像リクエストだけをブロックしてみました。
test.beforeEach(async ({ page }) => {
await page.route('**/*.{png,jpg,jpeg,webp}', (route) => route.abort());
});
これだけで、一覧画面のテストが目に見えて速くなりました。もともとこのテストは画面の見た目ではなく一覧の件数を確認するためのものだったので、画像を待つ必要自体がなかったわけです。Speedboardで順位を見て、タイムラインで太い区間を見て、直したい箇所にpage.routeを当てる。この一連の流れが、勘に頼らず遅さの原因にたどり着ける手順として使えそうだと感じました。
console.timeで探していた頃は、こういう「疑ってすらいなかった箇所」にはまず気付けませんでした。ランキングとタイムラインという2段構えで見られるようになったことで、原因の見当を付ける時間そのものが大きく短縮された印象です。
AIエージェントに調べさせる場合はどうか
以前Playwright MCPでAIにブラウザを触らせる記事を書きましたが、遅いテストの調査もいずれエージェントに任せたくなる場面が出てくるはずです。SpeedboardやタイムラインはHTMLレポートという画面上のビューが前提になっているため、現状はエージェントが直接読み取るというより、人間がレポートを開いて目で見て判断する用途に向いていると感じます。
CLIだけで完結するtrace infoのような使い方に比べると、Speedboardは「まず人間が見て当たりを付け、原因が絞れたところでエージェントに深掘りさせる」という役割分担が今のところ現実的ではないでしょうか。この組み合わせ方は、私自身まだ試行錯誤中です。
バージョン表記について正直に書いておきます
この記事で紹介したSpeedboard自体は1.57、タイムラインは1.58というのが公式リリースノートで確認できた情報です。ただし世の中の解説記事の中には、Speedboardとタイムラインをまとめて1つのバージョンの機能として紹介しているものもあり、記事によって書きぶりに幅がありました。私が実際に手元で両方の挙動を完全に切り分けて再現できたわけではないので、細かい区分が気になる方は公式リリースノートで該当バージョンの項目を直接確認することをおすすめします。存在するかどうか怪しいオプションを手探りで叩くより、公式を見に行った方が結局早いです。
まとめ
「テストは通っているのに遅い」という状態は、失敗と違って原因がログに残らないぶん、放置されがちです。ですがSpeedboardで遅いテストを見つけて、タイムラインでその中身を見るという2段階の流れができたことで、勘に頼った調査から一歩抜け出せると感じました。
CIの実行時間に不満を持ち始めた方は、まずは手元のプロジェクトでnpx playwright show-reportを開いて、Speedboardのタブを覗いてみてください。予想もしていなかったテストが上位に来ることも珍しくないので、ちょっとした発見があるはずです。落ちたテストの原因調査についてはtrace CLIとVideo Receiptsの記事も合わせて読んでいただくと、遅さと失敗の両方を追う道具が揃います。
コメント