Sinon: Documentez comment configurer Node pour autoriser le remplacement des modules EcmaScript

J'ai pensé à écrire exactement ceci :)

Le "problème" est qu'il existe une pléthore de façons différentes d'utiliser esm , mais nous devrions au moins couvrir le cas le plus courant, qui, je suppose, est à travers le drapeau require au node processus. J'ai commencé à expliquer comment utiliser le fichier de configuration ici , mais il semble qu'il soit également possible de fournir une chaîne json en tant que variable d'environnement (, en plus d'un hachage d'options si vous utilisez du code).

Salut @ fatso83!

L'option cjs.mutableNamespace est activée par défaut, aucune configuration n'est donc nécessaire. Le stubbing fonctionnera avec .js mais pas avec .mjs _ (les fichiers .mjs sont verrouillés, donc pas d'options esm ) _.

@jdalton Merci de nous avoir fait part de la distinction js vs mjs . Cela explique pourquoi ce type n'a pas pu le faire fonctionner.

cc @ jim-king-2000

Je voudrais écrire un test unitaire avec le coût minimum. Si la solution était si délicate, je préférerais abandonner le test unitaire avec une simulation. Après tout, le test simulé n'est pas la méthode impérative pour construire un système en ligne robuste. Mais, en dernier recours, est-il possible que sinon enveloppe le "proxyrequire" (ou quelque chose comme ça) pour moi?

@ jim-king-2000 C'est hors de portée. Vous avez choisi explicitement d'utiliser un système de modules dont les exportations sont supposées être immuables. C'est malheureusement un coût que vous devrez assumer vous-même. Emballer les chargeurs de modules, les faire fonctionner dans toutes sortes de scénarios (nœud, navigateur, avec / sans transpileurs, etc.) est trop coûteux et n'a vraiment rien à voir avec les objectifs déclarés de ce projet .

Je ne comprends pas tout à fait la pertinence de sinon et du système de modules (je suis désolé). Ce dont j'ai besoin est un framework de test unitaire simulé js / node (ou une bibliothèque, comme l'homologue java, mockito) sans babel. Alors, existe-t-il?

En bref, pour votre niche spécifique: pas actuellement: sanglot:
En général: oui, il existe des moyens d'y parvenir pour presque toutes les combinaisons de frameworks et d'exécutions.

En termes Java, c'est comme implémenter tout votre système en utilisant les méthodes Java static , puis en essayant de simuler les classes à l'aide de Mockito. Cela ne peut pas être fait.

Cela étant dit, tout ce dont vous avez besoin pour faire fonctionner les choses est de renommer vos fichiers *.mjs en *.js . Cela semble être une voie intermédiaire pragmatique, car vous gagnerez en testabilité sans aucun inconvénient connu.

Pour la simulation de la fonction statique de Java, nous utilisons powermock. Mais je ne comprends peut-être pas entièrement la comparaison. Au fait, je n'aime pas java, son évolution est trop lente. Maintenant, il ne prend toujours pas en charge async / await.

J'utilise * .mjs partout, tous les codes sources sont des fichiers mjs. De plus, cela signifie que je dois à nouveau recourir à babel (en introduisant un travail supplémentaire de développement / d'exécution et une pile d'appels désordonnée). Ce n'est pas grave si je pouvais uniquement modifier les fichiers de test en * .js.

Je vais abandonner ut avec simulacre (les autres tests sont intacts) jusqu'à ce que je trouve d'autres moyens à faible coût.

@ fatso83 Merci pour votre aide.

Quelqu'un a-t-il essayé de chipoter ? 🤔

Pour info, j'ai implémenté le support ESM de Node.js dans "testdouble.js", qui est une bibliothèque moqueuse. C'est possible. J'ai écrit sur la mise en œuvre dans ce billet de blog:

https://dev.to/giltayar/mock-all-you-want-supporting-es-modules-in-the-testdouble-js-mocking-library-3gh1

Je serais heureux de vous aider ici si quelqu'un veut le faire.

@giltayar Félicitations pour la mise en œuvre du support ESM! Excellent article, btw. Nous avons toujours dit que le stubbing du module ES n'est pas possible pour se conformer aux Runtimes ESM, mais nous avons également dit (comme ci-dessus) que cela devrait être géré au niveau de la liaison, en utilisant quelque chose comme proxyquire, rewire ou ... Quibble, qui est où vous avez ajouté le support :)

Dans mon projet de travail, nous avons utilisé proxyquire pour extraire les dépendances des modules ES:

proxyquire('./mylib.mjs', {doSomething: () => 'done'})

Ce serait tout à fait équivalent dans Quibble (utilisé par TestDouble), où l'article a un exemple comme celui-ci, mais Quibble ne prend pas en charge les stubs partiels, donc c'est un peu différent dans ce qu'ils font.

await quibble.esm('./mylib.mjs', {doSomething: () => 'done'}, 'yabadabadoing') // not sure what this third param does ...

Donc, conformément à ce qui a été dit précédemment, Sinon n'ajoutera jamais explicitement la prise en charge des modules ES moqueurs, car il vaut mieux laisser cela à Quibble, Proxyquire, Rewire, NormalModuleReplacementPlugin (webpack) et toutes les autres façons de le faire qui sont 100% environnement dépendant.

@ fatso83 Si je peux demander pourquoi c'est un tel convaincu "ne jamais ajouter explicitement de support"? J'ai lu cela plusieurs fois ici au cours des derniers jours en cherchant désespérément une solution pour se moquer du code de mon module ES6.

Aucune solution documentée chez Jest, aucune n'est ici. J'ai failli abandonner jusqu'à ce que je trouve l'article de @giltayar. Quel soulagement. J'ai quelque chose qui fonctionne avec Quibble jusqu'à ce que je réalise que je peux simplement utiliser testdouble.js.

Il est déjà assez difficile qu'en JavaScript, chaque paquet ait son propre style de documentation et la plupart du temps pas de vrais documents API, mais aussi avoir à comprendre comment fonctionnent les bibliothèques de test, les bibliothèques moqueuses et les chargeurs de modules pour les bibliothèques moqueuses fonctionnent, c'est tout simplement trop .

Je suis tout à fait d'accord si vous dites que vous vous concentrez sur Sinon tel qu'il est alors que d'autres peuvent se concentrer sur le câblage de ces paquets ensemble pour le programmeur "utilisateur final". Je veux seulement montrer qu'il y a une vraie douleur pour les programmeurs comme moi et je suis sûr que beaucoup seraient heureux si le processus se simplifiait, surtout si beaucoup passeraient aux modules ES dans les années à venir.

Je n'ai pas une compréhension technique aussi profonde, j'ai juste pensé que des commentaires sur mon expérience pourraient être utiles

@ fatso83 Si je peux demander pourquoi c'est un tel convaincu "ne jamais ajouter explicitement de support"?

Permettez-moi de répéter: les responsables d'Autre sont d'avis que le traitement des importations moqueuses est hors de portée pour Sinon et qu'il est mieux traité par des bibliothèques spécialisées.

En général, cela n'a pas de sens de créer une bibliothèque qui essaie de tout faire, à chaque exécution. Même les projets open source plus grands et bien financés n'essaient pas de le faire.

Aucune solution documentée chez Jest, aucune n'est ici. J'ai failli abandonner jusqu'à ce que je trouve l'article de @giltayar. Quel soulagement. J'ai quelque chose qui fonctionne avec Quibble jusqu'à ce que je réalise que je peux simplement utiliser testdouble.js.

Différentes bibliothèques font des choix différents.

Les responsables de testdouble.js font leurs propres choix. Ils ont décidé de publier le chipotage et de l'intégrer dans leur bibliothèque. Bien pour eux. Si vous aimez leur solution, alors utilisez-la. Nous n'avons que de l'amour et du respect pour @searls et les mainteneurs de testdouble.js.

Il est déjà assez difficile qu'en JavaScript, chaque paquet ait son propre style de documentation et la plupart du temps pas de vrais documents API, mais aussi avoir à comprendre comment fonctionnent les bibliothèques de test, les bibliothèques moqueuses et les chargeurs de modules pour les bibliothèques moqueuses fonctionnent, c'est tout simplement trop .

Je suis tout à fait d'accord si vous dites que vous vous concentrez sur Sinon tel qu'il est alors que d'autres peuvent se concentrer sur le câblage de ces paquets ensemble pour le programmeur "utilisateur final". Je veux seulement montrer qu'il y a une vraie douleur pour les programmeurs comme moi et je suis sûr que beaucoup seraient heureux si le processus se simplifiait, surtout si beaucoup passeraient aux modules ES dans les années à venir.

Nous ne sommes pas ici pour résoudre tous les problèmes de l'éco-système JavaScript.

Depuis plus d'une décennie, divers responsables de la maintenance ont fourni gratuitement la famille de bibliothèques Sinon. Pratiquement tout le travail qui a été consacré à la maintenance de ces bibliothèques a été effectué en tant que travail non rémunéré, pendant le temps libre des responsables. Nous utilisons nous-mêmes JavaScript de manière professionnelle et partageons vos frustrations. Mais nous n'avons que peu de temps à offrir gratuitement.

Je n'ai pas une compréhension technique aussi profonde, j'ai juste pensé que des commentaires sur mon expérience pourraient être utiles

Ce qui serait utile serait si vous écriviez un article de blog sur vos frustrations en se moquant des dépendances, jusqu'à ce que vous trouviez une solution qui a bien fonctionné pour vous, et comment vous avez utilisé testdouble.js avec beaucoup de succès avec votre manière particulière de charger JavaScript.

S'il s'avère être un article de blog solide, je serais heureux de le promouvoir sur sinonjs.org .

@mroderick J'imagine que j'aurais dû d'abord préciser que vous et les responsables Sinon avez mon plus grand respect!

Nous ne sommes pas ici pour résoudre tous les problèmes de l'éco-système JavaScript.

Certainement pas, c'était juste pour montrer qu'il pourrait y avoir un plus grand besoin d'aide qu'avec d'autres langues (juste à mon avis).

le traitement des importations moqueuses est hors de portée pour Sinon et est mieux traité par des bibliothèques spécialisées.

Assez juste, comme je l'ai dit, je peux comprendre cela et vous avez probablement une compréhension beaucoup plus profonde de l'effort impliqué par la mise en œuvre de ces fonctionnalités. L'API du chargeur est également encore expérimentale.

Je travaille actuellement sur un petit outil CLI que je prévois de publier en open source dès qu'il y aura une version fonctionnelle. Si cela est fait, j'envisage d'écrire un article de blog à ce sujet. J'essaierai encore Sinon avec proxyquire avant, car j'ai lu trop de bonnes choses sur Sinon.

J'essaierai encore Sinon avec proxyquire avant, car j'ai lu trop de bonnes choses sur Sinon.

Nous avons un guide sur la façon de faire cela: https://sinonjs.org/how-to/link-seams-commonjs/

Si vous trouvez que le guide peut être amélioré, veuillez envoyer une demande d'extraction