テスト

Google Ads API の統合を成功させるには、テストが重要なステップとなります。これは、統合を始めたばかりの場合でも、アプリを維持する場合でも、既存の統合に新機能を追加する場合でも同様です。このガイドでは、Google Ads API 統合をテストするためのベスト プラクティスを紹介します。

テスト アカウントと本番環境アカウント

テスト アカウントの保持に関する注意事項:

Google Ads API テスト アカウントとそれに関連するデータは、自動削除の対象となります。1 年間連続して非アクティブ（API アクティビティやログインがない）のテスト アカウントは、完全に削除されます。

意図しない削除を防ぐため、テスト アカウントを保持する場合は、定期的にテスト アカウントを操作してください。

開発目的でテスト アカウントを利用できます。テスト アカウントを使用すると、アプリケーション コードと構成が意図したとおりに動作していることを検証できます。

ただし、テスト アカウントでテストできるのは一部の機能のみです。

テスト アカウントの制限により、統合の一部の機能をテストできない場合は、代わりに本番環境アカウントを開発に使用できます。本番環境アカウントを呼び出すには、Google Cloud プロジェクトに少なくともエクスプローラ アクセスレベル（エクスプローラ、ベーシック、スタンダード）が必要です。なお、Explorer アクセスでは、請求（BillingSetupService と AccountBudgetProposalService）、プランニング、アカウントの作成、ユーザーの招待など、特定のサービス（Explorer 機能の制限を参照）が制限されます。これらのサービスには、ベーシック アクセスまたはスタンダード アクセスが必要です。テスト アクセスレベルのプロジェクトから本番環境アカウントを呼び出そうとすると、v25 以降では AuthorizationError.CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION が返され、v24 以前では AuthorizationError.ACTION_NOT_PERMITTED が返されます。

開発用の本番環境アカウントは、テスト アカウントと次の点で異なります。

• ユーザーに表示される広告を配信する
• 有効な URL を必須にする
• 広告掲載のポリシーに準拠している必要があります

本番環境アカウントは広告を配信するため、パフォーマンス レポートをテストできる指標が生成され、Google Ads API の他のすべての機能が利用可能になります。ただし、開発に使用する場合は、特に注意が必要です。次の対策を講じることをおすすめします。

• アクセス権は、開発目的で必要なユーザーにのみ付与します。
• アカウントの 1 日の予算を低く固定します。
• テスト アカウントを使用できない場合にのみ、開発に本番環境アカウントを使用します。

そのため、統合の完全なテストを行うには、テスト用認証情報と本番環境用認証情報の両方が必要になる可能性があります。

テスト用認証情報

開発アカウントを変更しようとしたときに本番環境アカウントを誤って変更するリスクを最小限に抑えるため、本番環境アプリケーションの認証情報とは別のテスト認証情報のセットを維持することをおすすめします。

テスト認証情報のセットを作成する手順は次のとおりです。

1. テスト専用のメール アカウント（[e-mail] など）またはサービス アカウントを作成します。
2. このユーザーまたはサービス アカウントを、テストの対象となる Google 広告アカウントの有効なユーザーとして追加します。このユーザーまたはサービス アカウントに適切なアクセスレベルを付与してください。このユーザーまたはサービス アカウントに本番環境アカウントへのアクセス権を付与しないでください。
3. サービス アカウント フローではなく OAuth 2.0 ユーザー認証フローを使用している場合は、テスト ユーザー アカウントの更新トークンを生成します。
4. アプリケーションのテストには、これらの新しい認証情報を使用します。クライアント ID とクライアント シークレットは、アクセス可能な Google 広告アカウントの決定に影響しないため、テスト目的で再利用できます。すべての認証情報と更新トークンを安全に保存し、ソース管理に commit しないでください。

リクエストの検証

リクエストが有効かどうかをテストするだけの場合（リクエストが正しく構造化され、ポリシーに違反していないことを確認するなど）、validate_only フィールドを使用できます。このフィールドは、GoogleAdsService.Search リクエスト（GoogleAdsService.SearchStream は validate_only をサポートしていません）とほとんどの変更リクエストで使用できます。リファレンス ドキュメントを参照して、特定のメソッドでこのフィールドが使用可能かどうかを確認します。

注: v25 以降、スマート キャンペーンの P-MAX キャンペーンの生成では validate_only モードがサポートされず、validate_only が true に設定されている場合は SmartCampaignError.VALIDATE_ONLY_GENERATE_PMAX_NOT_SUPPORTED が返されます。

REST API

リクエストが期待どおりの出力を生成することを確認するなどのアドホック テストでは、REST API を使用するのが最も簡単な方法です。REST API へのリクエストで curl を使用する方法については、REST の例をご覧ください。REST エクスプローラでテストすることもできます。