Testing Strategy in the Pipeline
A focused chapter on testing strategy in the pipeline, with practical delivery concerns, trade-offs, and the operational questions behind CI/CD work.
パイプラインにおけるテストの真の目的
開発者がコードをプッシュするたびに、「この変更は安全か？」という問いに答える必要があります。パイプラインのテストは、その問いに答えるために存在します。リスクベースのテスト選択、信頼性ゲートの設計、高速なフィードバックの実現方法を解説します。
パイプラインの最前線に単体テストを配置する理由
金曜の午後にコードをプッシュし、ビルドが通り、デプロイして帰宅。土曜の朝、アラートで電話が鳴る。割引計算が顧客注文に負の値を適用している。単体テストがあれば防げたはずのバグ。本記事では、CI/CDパイプラインにおける単体テストの役割、分離の原則、配置場所、そして十分なテスト量の判断基準を解説します。
統合テスト：コンポーネント間の連携で問題を発見する
ユニットテストでは見つけられない、コンポーネント間の想定の不一致を発見する統合テストの実践ガイド。データベース、外部API、内部サービスごとのテスト戦略と、パイプラインへの組み込み方を解説します。
コントラクトテスト：壊れたAPIの約束を本番環境に届く前に検出する
ユーザーサービスの変更をデプロイしたら、全テストがパスしパイプラインもグリーン。しかし5分後、通知サービスが本番環境でエラーを吐き出す。原因は、自サービスでは使っていないが通知サービスが依存していたAPIレスポンスのフィールドを削除したこと。この問題を防ぐのがコントラクトテストです。
E2Eテスト：役立つケースとパイプラインを遅くするだけのケース
ユニットテスト、結合テスト、契約テストがすべてパスしても本番で障害が起きる。E2Eテストの真の価値とコスト、そしてパイプラインを破綻させずに活用する実践的戦略を解説。
スモークテストとシンセティックトランザクション：デプロイが実際に機能していることを確認する
パイプラインがグリーンでも本番環境で壊れることはある。スモークテストとシンセティックトランザクションで、デプロイの成否を本番環境で検証する方法を解説。
パイプラインの各ステージでテストをどこに配置すべきか
パイプライン設計の核心は、各テストタイプを最も価値が高くコストが低いステージに配置することです。ユニットテストはコミットステージ、結合テストはビルドステージ、E2Eテストはステージング、スモークテストは本番とステージングに配置する実践的なガイドです。
パイプラインが判断を下すとき：テスト結果を証拠として活用する
パイプラインがテスト結果を証拠として活用し、一貫性のある信頼できるデプロイ判断を下す方法を解説。テストゲーティング、しきい値、誤検知対策、手動ゲートの実践的アプローチを紹介。