Tests

Les tests sont une étape importante pour créer une intégration réussie de l'API Google Ads, que vous débutiez, que vous gériez une application ou que vous ajoutiez de nouvelles fonctionnalités à une intégration existante. Ce guide présente quelques bonnes pratiques pour tester votre intégration de l'API Google Ads.

Comptes de test et comptes de production

Des comptes de test sont disponibles à des fins de développement. Les comptes de test vous permettent de vérifier que le code et la configuration de votre application fonctionnent comme prévu.

Cependant, toutes les fonctionnalités ne peuvent pas être testées dans un compte de test.

Lorsque les limites des comptes de test vous empêchent de tester certaines fonctionnalités de votre intégration, vous pouvez utiliser un compte de production pour le développement. Votre projet Google Cloud doit disposer au moins du niveau d'accès Explorateur (Explorateur, Standard ou Basique) pour appeler un compte de production. Notez que l'accès Explorateur limite toujours certains services, y compris la facturation (BillingSetupService et AccountBudgetProposalService), la planification, la création de comptes et les invitations d'utilisateurs (voir Restrictions des fonctionnalités de l'accès Explorateur), qui nécessitent un accès Standard ou Basique. Si vous tentez d'appeler un compte de production à partir d'un projet avec le niveau d'accès "Test", l'erreur AuthorizationError.CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION est renvoyée à partir de v25, ou l'erreur AuthorizationError.ACTION_NOT_PERMITTED dans v24 et les versions antérieures.

Les comptes de production pour le développement diffèrent des comptes de test de la manière suivante :

Comme les comptes de production diffusent des annonces, ils génèrent des métriques qui vous permettent de tester les rapports sur les performances et de débloquer toutes les autres fonctionnalités de l'API Google Ads. Toutefois, leur utilisation pour le développement nécessite une attention particulière. Nous vous recommandons de prendre les mesures suivantes :

  • N'accordez l'accès qu'aux utilisateurs qui en ont besoin à des fins de développement.
  • Définissez un budget de compte quotidien fixe et faible.
  • N'utilisez des comptes de production pour le développement que lorsque les comptes de test ne peuvent pas être utilisés.

Par conséquent, pour tester entièrement votre intégration, vous aurez probablement besoin d'identifiants de test et d'identifiants de production.

Identifiants de test

Pour minimiser le risque de modifier accidentellement des comptes de production lorsque vous essayez de modifier des comptes de développement, nous vous recommandons de conserver un ensemble d'identifiants de test distincts des identifiants de votre application de production.

Pour créer un ensemble d'identifiants de test, procédez comme suit :

  1. Créez un compte de messagerie (par exemple, api.test@example.com) ou un compte de service qui ne sera utilisé qu'à des fins de test.
  2. Ajoutez ce compte utilisateur ou de service en tant qu'utilisateur valide dans les comptes Google Ads sur lesquels vous effectuez vos tests. Veillez à accorder les niveaux d'accès appropriés à cet utilisateur ou à ce compte de service. N'accordez pas à cet utilisateur ou à ce compte de service l'accès à des comptes de production.
  3. Si vous utilisez le flux d'authentification des utilisateurs OAuth 2.0 plutôt que le flux de compte de service, générez un jeton d'actualisation pour votre compte utilisateur de test.
  4. Utilisez ces nouveaux identifiants lorsque vous testez votre application. L'ID client et le code secret du client peuvent être réutilisés à des fins de test, car ils n'ont aucune incidence sur la détermination des comptes Google Ads accessibles. Stockez tous les identifiants et jetons d'actualisation de manière sécurisée, et ne les validez jamais dans le contrôle des sources.

Demande de validation

Si vous souhaitez simplement vérifier si une requête est valide (par exemple, pour vérifier qu'elle est correctement structurée et qu'elle ne va pas à l'encontre des règles), vous pouvez utiliser le champ validate_only, disponible pour les requêtes GoogleAdsService.Search (notez que GoogleAdsService.SearchStream n'est pas compatible avec validate_only) et la plupart des requêtes de modification. Consultez la documentation de référence pour vérifier si ce champ est disponible pour une méthode donnée.

API REST

Pour les tests ad hoc, par exemple pour vérifier qu'une requête génère le résultat attendu, l'utilisation de l'API REST est souvent l'option la plus simple. Consultez les exemples REST pour savoir comment utiliser curl pour envoyer des requêtes à l'API REST. Essayez également de tester dans l'explorateur REST.