ゲートとは「止める基準」を決める仕事だ

一言でいうと

テストゲートの本質は、テストをたくさん実行することではなく、どんなシグナルが出たらマージを止めるかを事前に合意し、その判定を機械に任せることです。

なぜ必要なのか

欠陥は、見つけるのが遅いほどコストが高くなります。IBMの研究として広く引用される倍率は、開発段階が1、QAが10、本番環境が100以上です。同じバグでも、自分のブランチで見つければ30分で済みますが、本番環境で見つけると、障害対応・ホットフィックス・振り返り・顧客とのコミュニケーションまで付いてきます。ゲートは、このコスト曲線の左端で捕まえるために置く仕組みです。

問題は、どのテストをどれだけ置くかです。テストピラミッドの推奨比率は、ユニット70、統合20、E2E 10です。これが逆さになった逆ピラミッド(アイスクリームコーン)になると、4つの問題が一度に来ます。E2Eは遅いのでフィードバックループが長くなり、フレーキーが頻発し、失敗しても原因がどこなのかを把握しにくく、メンテナンスコストが指数関数的に増えます。テストは増えたのに誰も結果を信じていない状態が、まさにこの形です。

どう動くのか

ゲートは3つの部分に分かれます。

1つ目は判定基準です。カバレッジは、コアのビジネスロジックで80%以上、全体で60–80%を目標にします。ただし、100%のカバレッジより、意味のあるassertionを持つテストのほうが重要だという原則を忘れてはいけません。数字だけを合わせるテストは、カバレッジレポートを見栄えよくするだけで、バグはそのまま通してしまいます。

2つ目はブロックのポリシーです。ユニットと統合は必ずブロックします。E2Eは主要なフローだけをブロックし、残りは観察にとどめます。性能はしきい値を超えたときだけ、セキュリティスキャンはCRITICALだけをブロックします。カオステストは非ブロックにして、メトリクスだけを見ます。すべてをブロックにすると、人々はゲートを回避する方法を先に覚えます。

3つ目は強制ポイントです。ゲートが実際に強制される場所は、パイプラインのスクリプトではなく、ブランチ保護のrequired status checksです。スクリプトは結果を作るだけで、マージを止める権限はリポジトリの設定が持ちます。IaCにも同じ型があります。PlanはPRで見せ、Applyはマージ後に自動で実行します。

フレーキーテストはゲートの信頼を損なう主犯なので、別に扱う必要があります。固定のsleepの代わりに特定の条件を待つ明示的な待機を使い、テスト間の依存を断ち切り、ネットワークはモックにするか上限のあるリトライで包み、日付のような動的データは固定します。リトライには必ず上限が必要です。無限リトライは安定化ではなく、失敗を隠すことです。それでも不安定なテストは隔離リストに入れてマージを止めないようにしますが、隔離されているという事実をレポートに残して、忘れられないようにします。

現場での姿

ゲートを初めて有効にすると、必ず「今すぐ急ぎなのに、これのせいで出せない」という依頼が来ます。そのとき必要なのは例外承認の手続きであり、ゲートを切るスイッチではありません。もう1つよく見る場面は、失敗したテストを直す代わりにリトライ回数を増やすことです。リトライ回数は増えるのに失敗率が変わらないなら、そのテストはすでにシグナルではなくノイズです。

ゲートは速くなければ守られない

人々がゲートを回避する最大の理由は、ルールが厳しいからではなく遅いからです。マージまで40分待たなければならないと、開発者は小さな変更をためて大きな塊で上げるようになり、大きな塊はレビューしにくく、元に戻すのも困難です。ゲートの目的がまさにその正反対だったことを考えると、これは単なる不便ではなく設計の失敗です。

速度を得る方法は決まっています。

• 変更されたものだけを実行します。モノレポなら、どのパッケージが変わったかを見て、その影響範囲だけをテストします。単一のリポジトリでも、ドキュメントだけが変わったコミットに全体のテストを実行する理由はありません。
• ステップを分けます。速いものを先に実行して数分以内に失敗を知らせ、遅いものはその後ろに置きます。前のステップで落ちたら後ろはそもそも開始しないので、平均の待ち時間が大きく減ります。
• 並列で実行します。テストをいくつかに分けて同時に実行します。このとき、テスト同士が状態を共有していると、並列化がそのまま不安定さに変わるので、各テストが自分のリソースを自分で作って片付けることが前提です。
• キャッシュします。依存関係のインストールが毎回数分かかるなら、まずそこを直します。テストコードを減らすより効果が大きいです。

時間を測ることも忘れてはいけません。パイプラインの各ステップの所要時間を記録しておけば、ある日突然遅くなったときに原因を探せます。この記録がないと、「最近CIが遅い」という言葉ばかりが繰り返され、何がいつから遅くなったのかを誰も答えられません。

最後に、ゲートの成否を分ける文化的な条件が1つあります。赤いパイプラインを放置しないことです。mainが壊れたまま1日が過ぎると、その後に上がってくるすべての変更が自分のせいなのかどうか判断できなくなり、ゲートはシグナルとしての機能を完全に失います。壊れたら、直すか元に戻すことが、ほかのどんな作業よりも優先されるという合意が必要です。元に戻すほうがほとんどいつも速いので、原因がまだわからなくても、まず戻してmainを緑にしてから調べるのがセオリーです。

次のラボですること

テストランナーとカバレッジゲート、リトライ、隔離をシェルで自作します。失敗しても残りを最後まで実行して全体像を見せるランナー、境界値で正確に判定するカバレッジゲート、上限のあるリトライ、そして数値と判定が一致するJSONレポートを作ります。