テストは、Google 広告 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 の例をご覧ください。