Google Ads API の統合を成功させるには、テストが重要なステップとなります。これは、統合を始めたばかりの場合、アプリを維持する場合、既存の統合に新機能を追加する場合のいずれにも当てはまります。このガイドでは、Google Ads API の統合をテストする際のベスト プラクティスをいくつか紹介します。
テスト アカウントと本番環境アカウント
開発目的でテスト アカウントを利用できます。テスト アカウントを使用すると、アプリケーション コードと構成が意図したとおりに動作していることを検証できます。
ただし、テスト アカウントでテストできるのは一部の機能のみです。
テスト アカウントの制限により統合の一部の機能をテストできない場合は、代わりに本番環境アカウントを開発に使用できます。開発用の本番環境アカウントは、テスト アカウントと次の点で異なります。
- ユーザーに表示される広告を配信する
- 有効な URL を必須にする
- 広告ポリシーに準拠している必要があります
本番環境アカウントは広告を配信するため、パフォーマンス レポートをテストできる指標が生成されます。また、Google Ads API の他のすべての機能も利用できるようになります。ただし、開発に使用する場合は、特に注意が必要です。次の対策を講じることをおすすめします。
- アクセス権は、開発目的で必要なユーザーにのみ付与します。
- アカウントの 1 日の予算を低く固定します。
- テスト アカウントを使用できない場合にのみ、開発に本番環境アカウントを使用します。
そのため、統合の完全なテストを行うには、テスト用認証情報と本番環境用認証情報の両方が必要になる可能性があります。
テスト用認証情報
開発アカウントを変更しようとしたときに本番環境アカウントを誤って変更するリスクを最小限に抑えるため、本番環境アプリケーションの認証情報とは別のテスト認証情報のセットを維持することをおすすめします。
テスト認証情報のセットを作成するには:
- テスト目的でのみ使用するメール アカウント（api.test@example.com など）またはサービス アカウントを作成します。
- このユーザーまたはサービス アカウントを、テストの対象となる Google 広告アカウントの有効なユーザーとして追加します。このユーザーまたはサービス アカウントに適切なアクセスレベルを付与してください。このユーザーまたはサービス アカウントに本番環境アカウントへのアクセス権を付与しないでください。
- サービス アカウント フローではなく OAuth 2.0 ユーザー認証フローを使用している場合は、テスト ユーザー アカウントの更新トークンを生成します。
- アプリケーションのテストには、これらの新しい認証情報を使用します。開発者トークン、クライアント ID、クライアント シークレットは、どの Google 広告アカウントにアクセスできるかを判断するうえで影響がないため、テスト目的で再利用できます。
リクエストの検証
リクエストが有効かどうかをテストするだけの場合（リクエストが正しく構造化され、ポリシーに違反していないことを確認するなど）、GoogleAdsService.SearchStream リクエストと GoogleAdsService.Search リクエスト、およびほとんどの mutate リクエストで使用できる validate_only フィールドを使用できます。このフィールドが特定のメソッドで使用できるかどうかを確認するには、リファレンス ドキュメントをご覧ください。
REST API
リクエストが期待どおりの出力を生成することを確認するなどのアドホック テストでは、REST API を使用するのが最も簡単な方法です。REST API にリクエストを行う際に curl を使用する方法については、REST の例をご覧ください。また、REST エクスプローラでテストすることもできます。