テストの基本

このドキュメントでは、次のような基本的なテストのコンセプトについて説明します。

テストの種類

このガイドでは、コードの動作を確認する 3 つの一般的なテストについて説明します。

  • 単体テスト
  • 統合テスト
  • システムテスト

一般に、詳細レベルが高くなるほど、テストにかかる時間は長くなります。このドキュメントでは、上記のテストについて詳しく説明するとともに、速度と詳細レベルとの間でバランスを取る方法についても説明します。

単体テスト

単体テストは、コードの特定の部分に対するテストで、テスト範囲は狭くなります。このテストは、エッジケースの処理や入力検証など、開発プロセスで設定した前提条件をすばやく検証できます。

設計上、単体テストでは、Cloud Functions 自体や他の Google Cloud コンポーネントなどの外部依存関係との統合テストは行いません。モック フレームワークを使用すると、外部依存関係を疑似的に再現できます。

HTTP 関数の場合、HTTP フレームワークのラッピングを再現する必要があります。テスト フレームワークとモック フレームワークを組み合わせて関数の結果と期待値と比較することで、関数の動作を確認します。

統合テスト

統合テストでは、コードの部分間の相互作用を検証します。通常、テストにかかる時間は、それほど長くありません。たとえば、Cloud Functions の統合テストでは、Datastore や Cloud Vision などの他の Google Cloud サービスと関数の連携を確認できます。

Cloud Functions の単体テストと統合テストの主な違いはモックの量です。統合テストは、単体テストよりもモックが少なくなります。統合テストでは、HTTP リクエスト、Pub/Sub メッセージ、Storage オブジェクトの変更などの Cloud イベントをトリガーして応答する必要があります。

統合テストは、shim を使用してローカルで実行できます。

一部の非同期オペレーションでは定期的なポーリングが必要になることがあります。切り捨て型指数バックオフのポーリング方法をおすすめします。これは基本的なオペレーションのレイテンシと必要なポーリング頻度の両方を最小限に抑えることができます。切り捨て型指数バックオフは、ネットワーク アプリケーションの標準的なエラー処理方法で、クライアントはリクエスト間の遅延を増加させながら、失敗したリクエストを定期的に再試行します。

システムテスト

システムテストは、孤立したテスト環境で複数の Google Cloud コンポーネントにわたる Cloud Functions の関数の動作を検証します。他のテストよりも複雑になります。

テスト環境に Cloud Functions の関数をデプロイし、適切なイベントをトリガーすることで機能をテストします。ログの参照や目的の動作の確認を行い、機能を検証します。

開発環境、テスト環境、本番環境は分離する必要があります。密閉型のビルドにするには、固有の GCP プロジェクトとリソース名を使用して、テストリソースとプログラムで準備する必要があります。

テスト環境のプロビジョニング

同時に実行するテストが相互に干渉しないように、グローバルに一意の名前をシステムテストのリソースに割り当てることも必要です。テストを実行する前後に、必要なリソースの作成や削除をプログラムで行うことで、このような名前を割り当てることができます。