Google Ads API の統合を成功させるうえで、テストは重要なステップです。使い始めたばかりの場合も、アプリの保守を行う場合や、既存の統合に新しい機能を追加する場合もテストは重要です。このガイドでは、Google Ads API の統合をテストするためのおすすめの方法を紹介します。
テスト アカウント
テスト アカウントは開発目的に使用できます。テスト アカウントですべての機能をテストできるわけではありませんが、アプリケーションのコードと構成が意図したとおりに動作していることを検証するための便利なツールです。
開発用の本番環境アカウント
テスト アカウントの制限によって統合の一部の機能をテストできない場合は、代わりに本番環境アカウントを開発に使用できます。開発用の本番環境アカウントは、次の点でテスト アカウントとは異なります。
- ユーザーに表示される広告を配信する
- 有効な URL を必須にする
- 広告掲載のポリシーに準拠している必要があります。
本番環境アカウントでは広告を配信するため、パフォーマンス レポートをテストできる指標が生成され、Google Ads API の他のすべての機能を利用できるようになります。
同時に、これらを開発に使用する場合は特に注意が必要です。次の対策を講じることをおすすめします。
- 開発目的でアクセスを必要とするユーザーにのみアクセス権を付与します。
- アカウントの 1 日の予算を低めに固定して設定する。
- テスト アカウントを使用できない場合にのみ、開発用として本番環境アカウントを使用します。
テストの認証情報
開発用アカウントを変更する際に本番環境アカウントが誤って変更されるリスクを最小限に抑えるため、本番環境アプリケーションの認証情報とは別の一連のテスト認証情報を維持することをおすすめします。
また、開発用に別の更新トークンを作成することをおすすめします。
更新トークンが生成されるのは、ユーザーがアプリに代理で Google Ads API にアクセスすることを承認したときです。つまり、各更新トークンには承認を行ったユーザーと同じアクセス権が与えられます。開発アカウントへのアクセスに使用されるすべての更新トークンが、本番アカウントにアクセスできないユーザー（本番環境アカウントを管理する MCC アカウントを含む）に関連付けられている場合、誤ってテスト更新トークンを使用して本番環境アカウントを変更するリスクが軽減されます。
アクセスは使用される更新トークンに依存するため、テスト用更新トークン以外のテスト用認証情報を作成する必要はありません。本番環境のアカウントへのアクセスに使用される開発者トークン、クライアント ID、クライアント シークレットは、更新トークンが異なっていれば、テスト アカウントへのアクセスに安全に使用できます。
リクエストの検証
リクエストが有効かどうかをテストするだけの場合（リクエストが正しく構造化され、ポリシーに違反していないことの確認など）は、validate_only フィールドを使用できます。このフィールドは、GoogleAdsService.SearchStream リクエストと GoogleAdsService.Search リクエストのほか、ほとんどの変更リクエストで使用できます。特定のメソッドでこのフィールドを使用できるかどうかを確認するには、リファレンス ドキュメントをご覧ください。
REST API
たとえば、リクエストが期待される出力を生成することを検証するアドホック テストでは、REST API を使用するのが最も簡単な方法です。cURL を使用して REST API にリクエストを送信する方法については、REST の例をご覧ください。