テスト

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

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

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

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

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

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

ただし、テストアカウントですべての機能をテストできるわけではありません。

テスト アカウントの制限により、統合の一部の機能をテストできない場合は、代わりに本番環境アカウントを開発に使用できます。本番環境アカウントを呼び出すには、Google Cloud プロジェクトに少なくともエクスプローラ アクセスレベル（エクスプローラ、ベーシック、スタンダード）が必要です。エクスプローラ権限では、お支払い（BillingSetupService と AccountBudgetProposalService）、プランニング、アカウントの作成、ユーザーの招待など、一部のサービスが制限されます（エクスプローラ機能の制限をご覧ください）。これらのサービスには、基本権限または標準権限が必要です。テスト アクセスレベルのプロジェクトから本番環境アカウントを呼び出そうとすると、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 を使用するのが最も簡単な方法です。curl を使用して REST API にリクエストを送信する方法については、REST の例をご覧ください。また、REST Explorer でテストしてみてください。