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 エクスプローラでテストすることもできます。