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