CI でのテスト

自動テストは、CI（コードを push するたびに自動でビルドとテストを流す仕組み）で動かしてはじめて効果が出ます。プルリクエストごとに流し、失敗したらマージできないようにするのが基本です。

• 段階に分ける：速いテスト（単体・型チェック）を先に流し、失敗したらすぐ知らせる。遅い E2E はその後、または主要なものだけをプルリクエストで、全部は夜間やリリース前に。

目安として、プルリクエストのテストが 10 分を大きく超えると、待ち時間が開発の邪魔になり始めることが多いです。

テストが増えて CI が遅くなったら、まず並列化を考えます。1台の中で複数のプロセスで流す方法と、複数のマシンに分割（シャード）して同時に流す方法があります。

• 並列化：テストを複数のマシンやプロセスに分けて同時に流す（Playwright では npx playwright test --shard=1/4 のように何番目かを指定して分割し、1台の中の並列数は workers で指定。分けたレポートは最後に1つにまとめる）。並列にすると、テスト同士がデータを共有していると壊れるので、テストの独立が前提です。
• 変更に関係するテストだけ流す仕組みもありますが、取りこぼしに注意し、全体も定期的に流します。

テストを流しても、失敗したままマージできてしまっては意味がありません。リポジトリのブランチの保護の設定で、「このチェックが通らないとマージできない」という条件（品質のゲート）を決めます。

ゲートを増やしすぎると、待ち時間が延びて「急ぎなので外して」と言われがちです。少なく・速く・必ず守るゲートにするのがこつです。

• 失敗したテストの名前・エラー・スクリーンショットやトレースを、CI の結果から1クリックで見られるようにする（HTML のレポートを成果物として保存する）。
• テストごとの成功率と実行時間の推移を記録し、flaky なテストや遅くなったテストを見つける。
• 失敗をチャットに通知する。ただし通知が多すぎると見られなくなるので、本流のブランチの失敗に絞るなど工夫する。

検証環境や本番にデプロイした直後に、主要な機能がそもそも動くかを短時間で確かめるのがスモークテストです（機械に電気を通して煙が出ないかを見る、が名前の由来）。