Google Ads API の統合を成功させるには、アプリの管理を始めたばかりの場合も、現在アプリを管理している場合も、既存の統合に新機能を追加する場合も、テストは重要なステップとなります。このガイドでは、Google Ads API の統合をテストする際のベスト プラクティスを紹介します。
テスト アカウント
テスト アカウントは開発に使用できます。テスト アカウントではすべての機能をテストできるわけではありませんが、アプリのコードと構成が意図したとおりに機能しているかどうかを検証するのに役立ちます。
開発用の本番環境アカウント
テスト アカウントの制限により、統合で一部の機能をテストできない場合は、代わりに本番環境アカウントを使用して開発を行うことができます。開発環境用の本番環境アカウントは、次の点でテスト アカウントとは異なります。
- ユーザーに表示される広告を配信する
- 有効な URL を必須にする
- 広告掲載のポリシーに準拠している必要があります。
本番用アカウントでは広告が配信されるので、パフォーマンス レポートのテストや、Google Ads API の他のすべての機能を利用するための指標が生成されます。
同時に、開発に使用する場合は特に注意が必要です。次の対策を実施することをおすすめします。
- 開発目的で必要とするユーザーにのみアクセス権を付与します。
- アカウントの 1 日の予算を低く固定して設定する。
- テスト アカウントを使用できない場合にのみ、開発に本番環境アカウントを使用してください。
認証情報をテストする
開発用アカウントを変更しようとしたときに、本番環境のアカウントを誤って変更するリスクを最小限に抑えるため、本番環境のアプリケーションの認証情報とは別に、一連のテスト認証情報を保持することをおすすめします。
また、開発用に更新トークンを個別に作成することもおすすめします。
更新トークンは、ユーザーがアプリに自分の代わりに Google Ads API にアクセスすることを承認したときに生成されます。したがって、各更新トークンは承認したユーザーと同じアクセス権を持ちます。開発アカウントへのアクセスに使用されるすべての更新トークンが、本番環境アカウント（本番環境アカウントを管理している MCC アカウントを含む）に関連付けられていないユーザーに関連付けられている場合、誤ってテスト更新トークンを使用して本番環境アカウントを変更するリスクを軽減できます。
アクセスは使用する更新トークンに依存するため、テスト更新トークン以外にテスト用認証情報を作成する必要はありません。本番アカウントへのアクセスに使用される開発者トークン、クライアント ID、クライアント シークレットは、更新トークンが他と区別できるものであれば、テスト アカウントに安全にアクセスできます。
リクエストの検証
リクエストが有効かどうかをテストするだけでよい場合（たとえば、リクエストが正しく構造化され、ポリシーに違反していないことを確認するなど）、GoogleAdsService.SearchStream リクエスト、GoogleAdsService.Search リクエスト、およびほとんどの変更リクエストで使用できる validate_only フィールドを使用できます。特定のメソッドでこのフィールドを使用できるかどうかを確認するには、リファレンス ドキュメントをご覧ください。
REST API
アドホック テスト（たとえば、リクエストが期待される出力を生成することを検証するなど）の場合は、REST API を使用するのが最も簡単なオプションです。cURL を使用して REST API にリクエストを送信する方法については、REST の例をご覧ください。