Jsdom: jest : SecurityError : localStorage n'est pas disponible pour les origines opaques

Résumé de la discussion ci-dessous :

• Le correctif consiste à définir une URL pour votre jsdom, ce qui peut être nécessaire via la configuration de votre environnement de test. L'URL par défaut, de " about:blank ", provoquera des erreurs lors de la tentative d'accès à localStorage.
• La cause première est souvent que les bibliothèques bouclent sur toutes les propriétés jsdom et les ajoutent au global ; même si vous n'utilisez jamais localStorage dans vos tests, une bibliothèque ou un framework de test dont vous dépendez "l'utilise" de cette manière. Notez que cette technique de bouclage et de copie n'est explicitement pas prise en charge , il n'est donc pas surprenant que le code qui le fait puisse se briser dans une version mineure.

Transcription du commentaire ci-dessous sur la question de savoir s'il s'agit d'un "changement de rupture", qui a depuis été masqué par la fonctionnalité "voir plus de commentaires" de GitHub :

Merci, mais pour le moment, je ne pense pas que ce soit la meilleure voie à suivre. Ce n'est pas un changement radical pour jsdom d'implémenter de nouvelles fonctionnalités de plate-forme Web ; c'est une version mineure.

Il est possible pour les dépendants, même les dépendants largement utilisés, d'écrire un code malheureux qui détecte les nouvelles fonctionnalités et lève une exception si elles apparaissent. J'espère que nous pourrons tous convenir que même si de telles dépendances existent, jsdom ne devrait pas abandonner pour toujours l'ajout de nouvelles fonctionnalités dans les versions mineures.

La situation ici n'est pas si drastique, mais semble être similaire. Je n'ai encore vu personne traquer le code Jest incriminé, donc c'est difficile à dire exactement, mais il semble qu'ils effectuent une opération qui est explicitement interrompue par le cours normal du développement de jsdom, et qui ne fonctionnerait pas dans un site Web navigateur qui implémente localStorage.

Je me rends compte qu'il s'agit d'une situation difficile pour ceux d'entre vous qui sont touchés, sans que ce soit de votre faute, par une interaction malheureuse concernant la façon dont votre dépendance directe utilise (ab)onnez votre dépendance indirecte. Mais j'espère que cela pourra être résolu au bon niveau, en corrigeant le code bogué de Jest, au lieu de supprimer une fonctionnalité utile de tous les utilisateurs de jsdom en raison des bogues d'une personne à charge.

Réponse originale au PO, pour le contexte :

Il semble probable que vous ne définissiez pas d'URL dans vos tests, mais vous, ou peut-être Jest, accédez à window.localStorage . Les responsables de Jest en savent peut-être plus sur la meilleure solution, mais j'ai entendu dire qu'il existe un moyen de définir des URL dans vos tests Jest ?

Il s'agit d'un problème très récent qui semble avoir surgi avec 11.12.0 . J'obtiens ces mêmes erreurs lors de l'utilisation de jest avec enzyme .

Oui, j'ai commencé à avoir le problème après la mise à niveau de 11.11.0 à 11.12.0 . La définition de testURL dans la configuration jest résout le problème.

@ben-mckernan Salut, Quelle est l'URL que tu as donné pour corriger ça ??

@gokulkrishh Je l'ai défini sur http://localhost/ mais toute URL valide semble fonctionner.

Je suppose que c'est probablement spécifique à Enzyme, car Enzyme fait la chose que la documentation jsdom met explicitement en garde de ne pas faire ? Pas trop surprenant qu'il s'est cassé sur une version mineure, malheureusement :(

C'est cassé pour moi aussi :(

@ben-mckernan Merci

Vivre cela aussi.

https://github.com/jsdom/jsdom/blob/23d67ebec901b3471b84e63f58a96b51a36f3671/lib/jsdom/browser/Window.js#L255

(Les commentaires "+1" seront marqués comme spam ; envoyer un e-mail à tout le monde dans le fil de discussion n'est pas utile.)

Excuses. J'essaie juste d'aider.

Peut confirmer l'ajout de testURL à jestConfig comme @ben-mckernan l'a suggéré.

Et nous utilisons également Enzyme, si cela peut confirmer votre intuition.

Pour le test d'application électronique, je l'ai simplement défini sur "file:/" qui fonctionne également.

@miamollie J'ai ajouté testURL selon la suggestion de @ben-mckernan (En utilisant Jest + Enzyme, je ne suis pas sûr que son enzyme soit lié. Erreur provenant de jest-environment-jsdom qui utilise jsdom). À cause de cela, mes autres fichiers de test échouent. Juste FYI. Voyez si cela fonctionne pour vous. Vos cas de test peuvent être différents des miens (TestURL peut fonctionner pour vous).

@domenic Je n'utilise que la plaisanterie. Je ne suis donc pas sûr que ce soit un problème d'enzyme.

@gokulkrishh Ouais, pareil, cela a arrêté l'erreur de sécurité localStorage mais a fait échouer d'autres tests.

La solution @ben-mckernan l'a corrigé. Merci!

@ben-mckernan J'utilise jest dans une configuration angulaire (avec jest-preset-angular), même bug, même solution. Ce n'est donc pas un problème enzymatique.

On dirait que Jest doit changer la valeur par défaut de testURL pour que cela soit atténué (actuellement c'est about:blank ).

@DcsMarcRemolt Je Jest utilise un module de dépendance appelé jest-environment-jsdom dans son package.json --> "jsdom": "^11.5.1" caret(^) à cause de ce npm a installé jsdom en tant que 11.12.0 (qui est la nouvelle version publiée aujourd'hui). Il s'est donc cassé pour la plupart des utilisateurs. Le problème est déjà créé en plaisantant et lié ici. Faites attention.

Je vais rouvrir ce numéro pour lui donner plus de visibilité. Voir le premier commentaire de Domenic pour une solution.

Ajout des éléments suivants à la configuration jest dans package.json :
"testEnvironment": "node"
résout le problème pour moi.
Merci à

Je ne peux plus écraser et moquer l'implémentation JSDOM sur localStorage depuis cette mise à jour.

Comme il s'agissait d'un changement radical involontaire pour beaucoup de gens, la meilleure option de contrôle des dégâts serait peut-être :

• Annulez cette modification.
• Publiez la version 11.12.1 avec la modification annulée pour restaurer le comportement attendu.
• Tirez ou désapprouvez la version 11.12.0 avec un avertissement.
• Si le nouveau comportement est souhaité tel quel, relâchez 12.0.0 pour indiquer qu'il y a un changement décisif.

Merci, mais pour le moment, je ne pense pas que ce soit la meilleure voie à suivre. Ce n'est pas un changement radical pour jsdom d'implémenter de nouvelles fonctionnalités de plate-forme Web ; c'est une version mineure.

Il est possible pour les dépendants, même les dépendants largement utilisés, d'écrire un code malheureux qui détecte les nouvelles fonctionnalités et lève une exception si elles apparaissent. J'espère que nous pourrons tous convenir que même si de telles dépendances existent, jsdom ne devrait pas abandonner pour toujours l'ajout de nouvelles fonctionnalités dans les versions mineures.

La situation ici n'est pas si drastique, mais semble être similaire. Je n'ai encore vu personne traquer le code Jest incriminé, donc c'est difficile à dire exactement, mais il semble qu'ils effectuent une opération qui est explicitement interrompue par le cours normal du développement de jsdom, et qui ne fonctionnerait pas dans un site Web navigateur qui implémente localStorage.

Je me rends compte qu'il s'agit d'une situation difficile pour ceux d'entre vous qui sont touchés, sans que ce soit de votre faute, par une interaction malheureuse concernant la façon dont votre dépendance directe utilise (ab)onnez votre dépendance indirecte. Mais j'espère que cela pourra être résolu au bon niveau, en corrigeant le code bogué de Jest, au lieu de supprimer une fonctionnalité utile de tous les utilisateurs de jsdom en raison des bogues d'une personne à charge.

Merci de clarifier. Je suis d'accord que si le problème provient de l'utilisation de jsdom d'une manière non prise en charge comme décrit ci-dessus, il ne s'agit pas techniquement d'une violation de semver et jest devrait publier un correctif.

Ma solution de contournement, utilisez une liste noire lorsque vous parcourez toutes les propriétés fichier global.

const { JSDOM } = require('jsdom');
const Node = require('jsdom/lib/jsdom/living/node-document-position');

// We can use jsdom-global at some point if maintaining these lists is a burden.
const whitelist = ['HTMLElement', 'Performance'];
const blacklist = ['sessionStorage', 'localStorage'];

function createDOM() {
  const dom = new JSDOM('', { pretendToBeVisual: true });
  global.window = dom.window;
  global.Node = Node;
  global.document = dom.window.document;
  // Not yet supported: https://github.com/jsdom/jsdom/issues/317
  global.document.createRange = () => ({
    setStart: () => {},
    setEnd: () => {},
    commonAncestorContainer: {
      nodeName: 'BODY',
      ownerDocument: document,
    },
  });
  global.navigator = {
    userAgent: 'node.js',
  };

  Object.keys(dom.window)
    .filter(key => !blacklist.includes(key))
    .concat(whitelist)
    .forEach(key => {
      if (typeof global[key] === 'undefined') {
        global[key] = dom.window[key];
      }
    });
}

module.exports = createDOM;

Ne chargez pas les globals jsdom sur le nœud global

Bon, je passe pour l'instant. J'ai besoin que les tests s'exécutent dans jsdom et dans de vrais navigateurs. C'est l'approche la plus simple à laquelle je puisse penser, elle fonctionne depuis des années. Je ne vois pas le même potentiel dans les alternatives proposées.
L'utilisation de jsdom-global pourrait également fonctionner.

Bon, je passe pour l'instant. J'ai besoin que les tests s'exécutent dans jsdom et dans de vrais navigateurs.

Si vos tests peuvent s'exécuter dans de "vrais navigateurs", ils peuvent également s'exécuter de la même manière dans jsdom - fournissez simplement le même code HTML. En attribuant au global à la place, vous introduisez une complexité et des différences supplémentaires par rapport à la façon dont vous exécuteriez le test dans un navigateur.

Pour info, je rencontre le même problème avec Mocha, pas Jest, après la mise jsdom niveau de 11.12.0 .

Salut, je veux juste comprendre pourquoi les changements sont introduits en premier lieu.

Mes cas d'utilisation consistent simplement à affirmer une fonction pour m'assurer que je l'ai écrite correctement, c'est aussi simple que :

const fib = require('./index');

test('Fib function is defined', () => {
  expect(typeof fib).toEqual('function');
});

test('calculates correct fib value for 1', () => {
  expect(fib(1)).toEqual(1);
});

et pourtant le résultat du test semble être des messages d'erreur que je viens de faire une grosse application sur React avec la bibliothèque Redux et des choses comme ça, alors que la vraie chose est que je teste simplement une fonction aussi simple que

//index.js, yes, only one line, no react no redux no enzyme 
function add(a, b) {}

Au fait, testURL et testEnvironment "hack" ne fonctionnent pas pour moi. Voici mon package.json :

    "jest": {
        "testURL": "http://localhost/",
        "testEnvironment": "node"
    },

donc ma question est pourquoi tous les tracas pour introduire des changements de rupture alors que parfois nous voulons juste un testeur qui "fonctionne"

@khmy2010 Votre code et vos questions impliquent plus Jest que jsdom. Je vous suggère plutôt de créer un problème dans leur référentiel .

Même message d'erreur avec l'op et presque tout le monde ici (sauf que je ne suis pas
à l'aide d'enzymes). Si ce n'est pas lié, je devrais ouvrir un problème pour plaisanter. Désolé de
cette.

Le 30 juil. 2018 21:32, "Zirro" [email protected] a écrit :

@khmy2010 https://github.com/khmy2010 Votre code et vos questions impliquent
Jest plus qu'ils ne le font jsdom. Je vous suggère de créer un problème dans leur
référentiel https://github.com/facebook/jest à la place.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/jsdom/jsdom/issues/2304#issuecomment-408864079 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AVrB3uOLy7l4JKbStKWPtGi0oHfAaQbYks5uLwrpgaJpZM4Vi8gP
.

Si vous créez votre instance jsdom , vous pouvez transmettre une URL personnalisée comme deuxième paramètre :

const url = 'http://localhost';
const jsdom = new JSDOM('<!doctype html><html><body></body></html>, { url });

Cela peut être utile si vous utilisez Enzyme + Mocha @srodrigo

Cela a cassé l'infrastructure existante. Cela devrait être la version majeure 12.0.0 et non la version mineure 11.12.0. Les versions mineures ne doivent pas casser le code existant.

Domenic explique dans ce commentaire (s'il ne s'affiche pas lorsque vous cliquez sur le lien, faites défiler vers le haut et chargez les commentaires cachés) pourquoi cela n'a pas été considéré comme un changement décisif. Le code des packages dépendants qui fait des choses que nous avons découragées depuis des années sera bientôt corrigé par leurs responsables.

En plus du correctif ci-dessus, j'ai dû ajouter ceci à la racine de la configuration de test : --env=jsdom

Ajouter ce qui suit à mon jest.config.js

testURL: 'http://localhost',

résolu le problème. Merci!

(Mainteneur de Jest ici.) Pensez-vous qu'il soit logique du point de vue de Jest de passer du about:blank par défaut à par exemple localhost ?

Je ne sais pas si je suis assez intelligent pour exprimer mon opinion à ce sujet, mais du point de vue du développeur, je dirais que localhost a plus de sens, about:blank est un cas qui n'est jamais une réalité. Nous testons nos applications qui n'ont pratiquement jamais à propos de : URL

L'équipe Jest a ajouté une valeur par défaut plus intelligente pour testURL : https://github.com/facebook/jest/pull/6792

@SimenB Je dirais que c'est une bonne idée.

Obtenir la même erreur que l'OP, mais dans ma situation, cela a causé BEAUCOUP de problèmes. Nous verrouillons les versions des packages que nous utilisons et nous ne pouvons les modifier qu'au début d'un cycle de publication. Nous sommes actuellement vers la fin du cycle de publication, nos environnements de développement ont donc les versions de tous les packages et de leurs dépendances il y a environ un mois, mais lorsque nous avons demandé au serveur de build de créer un build, il a récupéré la version actuelle de tous paquets. Ainsi, bien que tous les tests réussissent localement, ils échouent tous sur le serveur de build.

Nous utilisons l'option "setupTestFrameworkScriptFile" dans le fichier de configuration jest pour effectuer une configuration, y compris des polyfills pour (entre autres) localStorage et sessionStorage (puisque nous utilisons les deux dans notre application). C'est essentiellement window.localStorage = window.localStorage || { ... } , et la même chose pour sessionStorage, où ... est un tas de fonctions fictives. Maintenant, rien de tout cela ne fonctionne, même si je le modifie pour toujours remplacer la valeur par défaut ( window.localStorage = { ... } ).

De plus, nous avons des tests unitaires qui testent spécifiquement des choses comme l'appel de sessionStorage.getItem , mais après avoir défini "testURL" sur " http://localhost ", comme recommandé ci-dessus pour résoudre les erreurs de localStorage, celles-ci échouent toutes. Même si nous avons window.sessionStorage.getItem = jest.fn(); , faire un expect(window.sesssionStorage.getItem).toHaveBeenCalled() échoue en disant que ce n'est pas une fonction fictive.

Bien que je convienne que l'ajout d'une fonctionnalité est un changement de version mineur, et non un changement de rupture, lorsqu'il s'agit d'un élément standard des navigateurs et que la nouvelle implémentation ne peut apparemment pas être remplacée ou moquée, cela _est_ un changement de rupture .

La seule solution que j'ai trouvée à mon problème est d'ajouter jsdom à mon package.json et de spécifier une version de 11.11.0. Ce n'est pas idéal et entraînera un travail supplémentaire plus tard lorsque nous mettrons à niveau à nouveau les packages, mais au moins pour le moment, cela nous permet de débloquer.

Si vous avez du code, par exemple du code moqueur, qui fonctionne dans les navigateurs mais pas dans jsdom, déposez un nouveau problème en suivant le modèle de problème et nous pourrons enquêter. À ma connaissance, localStorage dans jsdom est exactement aussi moqueur que dans les navigateurs.

Je suggère de ne pas exécuter différentes versions sur votre serveur de build pendant que vos développeurs s'exécutent.

"Je suggère de ne pas exécuter différentes versions sur votre serveur de build pendant que vos développeurs s'exécutent."

Bien que cela semble bien en théorie, à moins que chaque développeur de packages n'arrête d'utiliser "^" lors de la spécification des versions de dépendances, ou que nous commencions les milliers de dossiers dans notre dossier node_modules, cela n'arrivera jamais. D'une machine de développeur à l'autre, il y aura probablement de légères différences dans certaines des dépendances d'un niveau ou deux. Tout ce que je peux faire est de spécifier les versions exactes des packages qui sont des dépendances directes de notre application.

https://docs.npmjs.com/files/package-locks

Entièrement d'accord avec @mrobrian à propos de "^". La chose la plus folle qui soit. npm devrait supprimer cette façon de décrire les dépendances.

La solution de contournement packge-lock.json et yarn.lock est cassée par conception. Peut-être que cela aide avec les versions, mais cela crée ensuite d'autres problèmes avec la révision du code et la fusion et vous devez souvent recréer ce fichier par suppression. Ce n'est pas grave si les dépendances sont rarement mises à jour, mais nous mettons à jour très souvent.

Donc notre .npmrc :

save-exact = true
package-lock = false

cela m'a aidé à ajouter ces nouvelles lignes au package.json :

"jest": {
    "verbose": true,
    "testURL": "http://localhost/"
  },

Si vous utilisez jsdom, assurez-vous d'inclure l'url

const dom = new JSDOM(``, {
URL : "https://example.org/",
});

Les développeurs de jest aimeraient-ils expliquer pourquoi "testEnvironment": "node" est désormais requis pour les projets CLI/nœuds (pour éviter l'erreur localStorage ) alors qu'auparavant, cela n'était pas nécessaire ? Est-ce un bug ?

Si c'est en quelque sorte par conception, il a vraiment besoin d'un meilleur message d'erreur ! J'obtiens cette erreur dans mes deux projets qui utilisent Jest - deux projets simples sans navigateur avec peu de dépendances. Ils n'utilisent certainement pas jsdom/localStorage.

Ce n'est pas le bon endroit pour poser des questions aux développeurs Jest - jsdom est un projet distinct. Cela dit, les commentaires ci-dessus contiennent déjà les réponses à vos questions.

package.json

   ...
  "jest": {
    "testEnvironment": "node",
    "roots": [
      "test/javascript"
    ]
  },

Ça marche pour moi.

@p8ul avait raison, n'oubliez pas de spécifier " http://localhost " (URL définie par défaut depuis Jest 23.5.0, voir #6792) :

const dom = new JSDOM(``, {
url: "http://localhost",
});

L'ensemble fonctionne pour moi.
Même pas besoin d'ajouter :

"testEnvironment": "node"

jest 23.5.0 inclut désormais un correctif pour cela, les solutions de contournement ne devraient donc plus être nécessaires :

https://github.com/facebook/jest/issues/6766#issuecomment -412516712

Similaire à @mica16 https://github.com/jsdom/jsdom/issues/2304#issuecomment -412663502

const dom = new JSDOM(``, {
  url: "http://localhost",
});

C'était le seul changement que nous devions faire pour éviter cette erreur.

Nous utilisons du moka/enzyme. Aucune plaisanterie incluse dans notre suite de tests.

La définition de --env node sur la ligne de commande fonctionne également.

@gokulkrishh Je l'ai défini sur http://localhost/ mais toute URL valide semble fonctionner.

"location.href" serait bien alors. :)

@domenic Je recommande de mettre à jour votre commentaire en haut pour dire que les responsables de Jest ont corrigé ce bogue dans la version 23.5.0 : https://github.com/facebook/jest/issues/6766#issuecomment -412516712

Je m'engage à définir le testURL pour jest-config sur http://localhost .

ajoutez la clé dans le fichier de configuration et réessayez "jest": { "testURL": " http://localhost%26quot%3B/ },
utiliser ip-port au lieu de localhost
Cela pourrait résoudre le problème

J'ai rencontré le problème après avoir repéré des problèmes de sécurité lors de l'exécution de npm audit . Après les avoir corrigés à l'aide de npm audit fix j'ai rencontré ce problème.

Puisque cela a été corrigé dans Jest depuis un certain temps, essayons de le fermer et de voir si nous nous retrouvons avec beaucoup de doublons, ou si les choses se sont suffisamment arrangées.

"blague": {
"verbose": vrai,
"testURL": " http://localhost/ "
}
Ajoutez cet extrait de code dans le fichier package.json.
Cela a fonctionné pour moi.

vous pouvez également l'ajouter au test concerné si jsdom n'y est pas nécessaire

``` javascript 1.6
/**

• nœud @jest-environment
  */

it('mon test', () => {
attendre(2 + 2).toBe(4);
});
```

J'ai testé les deux options :

1) Ajoutez ceci en haut d'un fichier de test :

/**
 * @jest-environment node
 */

2) Ajoutez cette strophe au package.json :

"jest": {
    "testURL": "http://localhost/"
  }

Les deux options ont fonctionné.

Je l'ai fait fonctionner en ajoutant dans le fichier package.json :

"jest": {
    "verbose": true,
    "testURL": "http://localhost/"
  }

@gokulkrishh Je l'ai défini sur http://localhost/ mais toute URL valide semble fonctionner.

Je suis un débutant. Pouvez-vous me dire exactement où dans le Jest.config.js j'ai défini l'URL de test ?

@haiphu n'importe où dans jest.config.js comme ci-dessous

{
"testURL": "http://localhost/"

// Your other config
}

J'ai ajouté le ci-dessous à mon package.json et cela fonctionne bien maintenant :)

  "jest": {
    "testURL": "http://localhost/"
  },

Je ne sais pas pourquoi, mais mon erreur a été causée par le fait d'avoir différentes versions dactylographiées.

J'ai une configuration mono-repo avec des espaces de travail de fil + lerna. Tous les packages avaient typescript@^3.3.3 dans leur package.json. J'ai ajouté un nouveau package et installé le dernier typescript@^3.5.3 . Lorsque j'ai exécuté des tests dans les packages existants, j'ai eu cette erreur.

Si je déplace tous les packages vers la même version - soit typescript@^3.3.3 ou typescript@^3.5.3 , l'erreur disparaît. Je n'ai pas eu à jouer avec le testURL .

@tylerreece22 @gokulkrishh A travaillé pour moi ! ??

Pour ceux qui se demandent ce que fait la directive de configuration testURL jest, voir https://jestjs.io/docs/en/configuration#testurl -string

Pour ceux qui définissent directement les options sur jsdom (lors de l'utilisation de Mocha par exemple). Mettez ceci dans votre setup.js :

let jsdom = require('jsdom-global')(
    undefined,
    {
        url: "http://localhost"
    }
);

Étrangement .. Je n'utilise pas jsdom .. J'utilise jest pour tester certains packages de nœuds uniquement, mais cette erreur a commencé à bloquer CI lors de la mise à niveau des versions de jest vers les dernières dans la plage de ^11 .. Je suis sûr que d'autres personnes voient des problèmes similaires .. aucun des changements recommandés jusqu'à présent ne semble le résoudre

si vous n'utilisez pas jsdom vous voudrez définir la propriété de configuration jest testEnvironment sur node . (pas besoin de toucher testURL )
https://jestjs.io/docs/en/configuration#testenvironment -string

Pour tous ceux qui recherchent le correctif réel, c'est new JSDOM('', { url: 'https://localhost' })

Essayez de l'utiliser dans votre fichier package.json

"blague": {
"verbose": vrai,
"testURL": " http://localhost/ "
}

Pourquoi la définition de l'url ne fonctionne pas pour moi... j'utilise react-native... y a-t-il autre chose qui me manque ?

Pourquoi la définition de l'url ne fonctionne pas pour moi... j'utilise react-native... y a-t-il autre chose qui me manque ?

On avait le même problème. Dans notre application, nous avions ce code

const { JSDOM } = require('jsdom');
const jsdom = new JSDOM('<!doctype html><html><body></body></html>');

Il s'avère que nous avons dû ajouter l'URL au constructeur JSDOM

const { JSDOM } = require('jsdom');
const jsdom = new JSDOM('<!doctype html><html><body></body></html>', {
  url: 'http://localhost/',
});

Cela a résolu le problème.

Pourquoi la définition de l'url ne fonctionne pas pour moi... j'utilise react-native... y a-t-il autre chose qui me manque ?

On avait le même problème. Dans notre application, nous avions ce code

const { JSDOM } = require('jsdom');
const jsdom = new JSDOM('<!doctype html><html><body></body></html>');

Il s'avère que nous avons dû ajouter l'URL au constructeur JSDOM

const { JSDOM } = require('jsdom');
const jsdom = new JSDOM('<!doctype html><html><body></body></html>', {
  url: 'http://localhost/',
});

Cela a résolu le problème.

Cela a fonctionné pour moi merci beaucoup! mettre l'url dans la configuration jest ne semble pas fonctionner avec react-native. mettre l'url dans le constructeur de jsdom a fait l'affaire.

Mettre à jour jest du 22 au 26 a résolu le problème.

utilisez simplement la dernière version de jest. actuellement, j'utilise 26.5.0 en 2020 et mon problème est résolu

Essayez de l'utiliser dans votre fichier package.json

"blague": {
"verbose": vrai,
"testURL": " http://localhost/ "
}

Cette testURL est l'URL par défaut, ce qui signifie qu'elle ne résout pas le problème, du moins pas avec Jest 26.x . J'ai dû faire ce que @zuccha a fait pour le contourner.