Geb Advent Calendar 2016 - Qiitaの12日目エントリーです。
先日の「JJUG CCC 2016 Fall」で「実録Blue-Green Deployment導入記」というテーマで発表しましたが、その中でインフラ観点でのシステムテストにGebを活用した事例の紹介をしました。
インフラのテストの観点の特徴としてあげられるのは、最終的な動作の確認をアプリケーション層に依存することがあげられます。
- 設定ファイルの項目の確認
- アプリケーションのプロセスが起動しているかの確認
- ヘルスチェックのURLにアクセスして行う疎通の確認
- サーバーおよびネットワーク機器間の疎通の確認
という観点まではServerspec等を用いたテストが可能ですが、それより上位レベルの観点はデプロイしたアプリケーション上の動作で確認することになります。
このような場合、インフラ側のテスト担当者が
- アプリケーション側の機能ドキュメント、テストケース一覧
- 過去のインフラ観点でのテストケース
- インフラ側のテスト担当者の勘
などを参照して、テストケースを作成します。
ですが、
- アプリケーションの規模
- サーバーやネットワーク構成
- 外部との連携先
などの構成が複雑になるにつれ、インフラのテスト担当者がアプリケーション観点でテストケースを作成することへのハードルはあがってきます。
また、この事例で取り上げたシステムの場合、システムが
- 「エンドユーザーからのアクセスを受け付けるモードか」(主系)
- 「動作確認のためのアクセスを受け付けるモードか」(副系)
の二つのモードをもっており、その結果として
- Blueサーバーが主系の場合のBlueサーバーへのアクセス
- Blueサーバーが主系の場合のGreenサーバーへのアクセス
- Greenサーバーが主系の場合のGreenサーバーへのアクセス
- Greenサーバーが主系の場合のBlueサーバーへのアクセス
で、一つのテストパターンについて、都合四通りのテストの組み合わせを実施することになりました。
そこで、この事例ではアプリケーションの観点から見たインフラのテストについて、全面的にアプリケーションの開発チームがGebによって作成したエンドツーエンドのテストを使用することになりました。エンドユーザー側から見た、アプリケーションの機能および外部サービスへの連携について、構築した環境上でGebによるエンドツーテストを実行し、その結果を確認することで、インフラ観点でのシステムテストを行うわけです。
このことによって、
- テストケースの作成コストの削減
- テストケースの網羅度、信頼性向上
- 組み合わせでテストを実行する場合の、実行コスト削減
という効果を得ることができました。
エンドツーエンドのテストを実装する場合、その効果はアプリケーションを開発する側のアプリケーションの修正に関わるコストの範囲内で語られがちです。しかし、エンドツーエンドの自動テストである程度の網羅性を担保することによって、インフラ側のテストの効率や精度の向上にも寄与することができる、というのが今回の事例で得られた知見です。
