E2Eテストをユニットテスト並みの実行時間に — Playwright並列化とGitHub Actionsチューニングの実践

E2Eテストでテストしたい項目は、アプリケーション操作（S項目）と合格判定基準項目（E項目）で構成される 1. 従来型 E2E テストが抱える問題 E2E テストの価値は誰もが認める一方で、「遅い・壊れやすい・維持できない」という問題は業界全体で長く指摘されてきました。 実行時間が長く、開発フローに載らない: Google Testing Blog の Just Say No to More End-to-End Tests（2015）は、E2E 偏重の戦略では実行時間と flake が膨張し、フィードバックが遅く失敗時の原因特定も難しいと指摘し、ユニット 70 / インテグレーション 20 / E2E 10 のテストピラミッドを推奨しました。 flaky（不安定）: Google は自社基盤で「全テスト実行の約 1.5% が flaky な結果を報告し、テスト全体の約 16% が何らかの

[pchatsu]

via https://x.com/naofumi/status/2079032265741598832

[strawberryhunter]

workers: 5（light）/ 3（heavy）か。並列度に重要なのは空きメモリだけど、GitHub Actionsの環境だから何も書いてないんだろう。ユニットテスト並みとか盛るから、てっきり複数マシンで分散テストでもするのかと思った。

[nguyen-oi]

E2Eテストが6分で終わるの環境として最高すぎる。Actionsの並列化とキャッシュの最適化は真似したい