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

Remarque sur la conservation des comptes de test :

Les comptes de test de l'API Google Ads et les données associées sont soumis à une suppression automatique. Tout compte de test qui reste inactif (aucune activité ni connexion à l'API) pendant une période continue d'un an sera supprimé définitivement.

Pour éviter toute suppression involontaire, assurez-vous d'interagir régulièrement avec vos comptes de test si vous souhaitez les conserver.

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

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

Lorsque les limites d'un compte de test vous empêchent de tester certaines fonctionnalités de votre intégration, vous pouvez utiliser un compte de production à la place pour le développement. Votre projet Google Cloud doit disposer au moins du niveau d'accès Explorateur (Explorateur, Basic ou Standard) 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 Explorateur), qui nécessitent un accès Basic ou Standard access. Toute tentative d'appel d'un compte de production à partir d'un projet avec le niveau d'accès Test renvoie AuthorizationError.CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION à partir de v25, ou 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 :

• Ils diffusent des annonces visibles par les utilisateurs.
• Ils nécessitent des URL valides.
• Ils doivent respecter les Règles en matière de publicité.

Étant donné que 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 prudence 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 du compte quotidien fixe et faible.
• N'utilisez les comptes de production pour le développement que lorsque les comptes de test ne peuvent pas être utilisés.

Par conséquent, pour tester complètement 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 de ceux 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, [e-mail]) ou un compte de service qui ne sera utilisé qu'à des fins de test.
2. Ajoutez cet utilisateur ou ce compte de service en tant qu'utilisateur valide dans les comptes Google Ads sur lesquels vous effectuez vos tests. Assurez-vous d'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 à aucun compte 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 client peuvent être réutilisés à des fins de test, car ils n'ont aucun effet sur la détermination des comptes Google Ads auxquels il est possible d'accéder. 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 avez juste besoin de tester si une requête est valide (par exemple, pour vérifier qu'elle est correctement structurée et qu'elle ne viole pas les règles), vous pouvez utiliser le champ validate_only, qui est 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 mutation. Consultez la documentation de référence pour vérifier si ce champ est disponible pour une méthode donnée.

Remarque : À partir de v25, la génération de campagnes Performance Max pour les campagnes intelligentes n'est pas compatible avec le mode validate_only et renvoie SmartCampaignError.VALIDATE_ONLY_GENERATE_PMAX_NOT_SUPPORTED si validate_only est défini sur true.

API REST

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