Résoudre les erreurs de mise à niveau d'exécution

Browser scripté : les tentatives d'interaction avec les éléments échouent

Lors de la validation d'un moniteur créé dans un environnement d'exécution plus ancien par rapport à l'environnement d'exécution Chrome 100 (ou plus récent), findElement et d'autres méthodes de recherche et d'interaction avec des éléments de la page peuvent échouer en raison de différences de gestion des promesses. Si le moniteur réussit dans un runtime legacy , échoue dans le nouveau runtime et que l'élément est présent dans la capture d'écran, vous devrez peut-être améliorer votre logique de gestion des promesses.

Le gestionnaire de promesses et le contrôle de flux Sélénium Webdriver permettaient à certaines fonctions de s'exécuter dans l'ordre dans les environnements d'exécution legacy , sans gérer les promesses. Cette fonctionnalité a été supprimée dans sélénium Webdriver 4.0 et n'est plus disponible dans l'environnement d'exécution. Toutes les fonctions asynchrones et les promesses doivent être gérées avec la chaîne de promesses await ou .then . Cela garantira que les fonctions de script s'exécuteront dans l'ordre prévu.

Par exemple, le gestionnaire de promesses et le flux de contrôle pourraient permettre à ce script partiel de se terminer avec succès, même si $browser.get renvoie une promesse et que la promesse n'est pas gérée correctement :

$browser.get('http://example.com');

$browser.findElement($driver.By.css('h1'));

Dans l'environnement d'exécution Chrome 100 (ou plus récent), toutes les méthodes qui renvoient une promesse doivent utiliser la syntaxe wait ou .then pour séquencer correctement les étapes. L'utilisation de wait est recommandée en raison d'une syntaxe plus claire et d'une utilisation plus simple, mais les chaînes de promesses .then sont également toujours prises en charge.

await $browser.get('http://example.com');

let el = await $browser.findElement($driver.By.css('h1'));

API scriptée : différences entre request et got

Les environnements d'exécution d'API scriptés Node.js 10 et antérieurs utilisaient le module Node.js request pour fournir un objet $http qui pouvait être utilisé pour tester les API.

Les environnements d'exécution d'API scriptés Node.js 16 et plus récents utilisent got au lieu de request. Le module request est obsolète en 2020 et ne sera plus inclus dans les nouvelles API ou les environnements d'exécution basés sur un navigateur. L'objet $http fournit une expérience personnalisée de type requesttout en étant alimenté par got pour fournir une compatibilité descendante pour les cas d'utilisation de base tout en évitant l'utilisation d'un module obsolète. Tous les cas d’utilisation avancés de request ne sont pas ou ne seront pas pris en charge. Des exemplesscript et un guide de conversion sont disponibles.

API scriptée : jeton inattendu JSON.parse

La tentative d'utilisation de la fonction JSON.parse lors de l'interaction avec le corps de la réponse peut produire des erreurs jeton inattendues dans le moniteur d'API scripté utilisant l'environnement d'exécution Node.js 16 et plus récent. Si l'en-tête de réponse de type de contenu est application/json, le corps de la réponse renvoyé par l'objet $http sera analysé au format JSON. Les appels supplémentaires tentant d'utiliser JSON.parse pour analyser le corps de la réponse échoueront avec cette erreur car le corps de la réponse a déjà été analysé.

Si l'en-tête de réponse de type de contenu n'est pas application/json, le corps de la réponse ne sera pas automatiquement analysé et la fonction JSON.parse devra toujours être utilisée.

API scriptée : HEAD ou GET

Vous ne pouvez pas inclure un corps de requête avec une requête HTTP HEAD ou GET . Le module request utilisé par le runtime Node 10 et les versions antérieures le permettait, mais cela entraînera des erreurs dans le nouveau runtime. Plusieurs configurations différentes peuvent provoquer l'erreur, mais les suggestions les plus courantes incluent :

• N'incluez pas de corps dans votre requête, même s'il est vide.
• Évitez les options inutiles sur votre demande HEAD ou GET , comme json: true

API scriptée : différences entre les chaînes de requête (qs)

Dans les environnements d'exécution Node 10 ou antérieurs, la configuration de la chaîne de requête était transmise à l'aide de l'option qs: . Pour l'exécution du nœud 16, utilisez plutôt l'option searchParams: . Seul le nom de l'option doit changer. Le contenu de la chaîne de requête ne devrait pas avoir besoin d’être mis à jour.

API scriptée : différences entre les pots à cookies

Dans les environnements d'exécution Node 10 ou antérieurs, vous pouvez utiliser l'option jar: true pour stocker les cookies dans un pot à cookies entre requests.

Dans l'environnement d'exécution Node 16, vous devez créer un pot de cookies à l'aide du module tough-cookie , puis faire référence à ce pot de cookies dans votre requête. Si vous avez créé un pot à biscuits nommé cookies, faites-y référence dans vos options comme cookieJar: cookies

API scriptée : différences de forme

En raison des différences entre le module request utilisé pour l'objet $http dans Node 10 et les environnements d'exécution plus anciens et le module got utilisé pour l'objet $http dans l'environnement d'exécution Node 16, vous pouvez rencontrer des problèmes avec requests utilisant des formulaires dans le moniteur d'API.

Si tel est le cas, veuillez utiliser le module form-data pour créer et inclure votre formulaire avec votre demande comme indiqué dans cet exemple partiel.

const FormData = require('form-data');

let form = new FormData();
form.set('fieldName1','value1');
form.set('fieldName2','value2');

let req = {
  headers: {
    'Authorization': 'Bearer ' + token,
    'Content-Type': 'multipart/form-data',
  },
  body: form
}

Différences entre les versions du module UUID

L'environnement d'exécution Node 16 inclut une version plus récente du module uuid qui force l'utilisation de la syntaxe require mise à jour.

Node 10 et versions antérieures : const uuid = require('uuid');

Nœud 16 (en supposant l'utilisation de uuidv4) : const { v4: uuidv4 } = require('uuid');

Navigateur scripté : avertissements d'obsolescence ($browser et $driver

Les avertissements d'obsolescence pour $browser et $driver ont été supprimés à partir de la version 2.0.29 ou plus récente de l'environnement d'exécution du navigateur. Vous ne devriez plus recevoir ces avertissements lorsque vous utilisez emplacement public. Veuillez mettre à jour l'image d'exécution de votre navigateur de nœuds si vous recevez ces avertissements lorsque vous utilisez le site privé.

Navigateur scripté : waitForAndFindElement et waitForPendingRequests

Les méthodes waitForAndFindElement et waitForPendingRequests sont des méthodes personnalisées New Relic fournies dans les environnements d'exécution de navigateur scriptés Chrome 72 et versions antérieures. Ils peuvent toujours être utilisés avec $driver et $browser dans les environnements d'exécution Chrome 100 et plus récents, mais ils ne seront pas disponibles lors de l'utilisation des API Sélénium Webdriver 4.1 directement avec $selenium et $webDriver. Ce changement permettra de mieux aligner l'implémentation du pilote Web Sélénium de New Relic avec l'implémentation de base du pilote Web Sélénium.

les clients qui choisissent de continuer à utiliser waitForAndFindElement ou waitForPendingRequests dans le nouveau runtime peuvent coller des exemples de code dans leur moniteur.