Je vois exactement le même problème. Les tests passeront, puis moka se bloque. Voir mon Travis CI:
https://travis-ci.org/mkrufky/node-dvbtee/builds/282593109

J'ai également remarqué ce même problème sur video-dev / hls.js - mocha se bloque juste après avoir réussi les tests:
https://travis-ci.org/video-dev/hls.js/builds/282590422

Avez-vous lu les notes de publication? https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit

Merci. tok bad le site Web de moka n'est pas mis à jour avec ce changement de rupture. Le cli soutient qu'il ne le mentionne pas.

En plus de fournir une solution rapide (utilisez --exit ), je suis d'accord qu'ils ont laissé à l'utilisateur le problème central de la recherche des tests défectueux. J'ai du mal avec cela moi-même maintenant, mais lors de la mise à niveau des versions majeures, je m'assure de lire les notes de publication et de ne pas mettre à niveau aveuglément

Les notes de publication suggèrent d'utiliser why-is-node-running sauf que cela ne fonctionne pas en raison de https://github.com/mafintosh/why-is-node-running/issues/7

Frappé par cela aussi. Je comprends le raisonnement derrière le changement de la valeur par défaut , et merci d'avoir incrémenté la version majeure, mais étant donné que why-is-node-running est abandonné et cassé, ce n'est peut-être pas le changement le plus convivial.

Salut à tous,

Tout d'abord, je tiens à m'excuser pour le chemin de mise à niveau approximatif sur ce point - nous sommes tout à fait d'accord que Mocha devrait dire à l'utilisateur ce qui maintient les tests en cours d'exécution (et il n'aurait même pas besoin de garder le processus ouvert; il pourrait simplement être une raison de renvoyer un échec une fois terminé), mais je n'ai pas encore trouvé de moyen entièrement satisfaisant de le faire. La version 4 n'a pas eu le temps que nous voulions y consacrer, car elle a été provoquée par l'échec de notre CI en raison de changements dans le programme d'installation de PhantomJS 1.x (package-lock.json aurait probablement empêché cela si nous avions eu il a été configuré à l'avance, mais nous ne pouvons toujours pas le faire fonctionner ). why-is-node-running était le seul outil que nous avons trouvé pour aider, mais nous ne pensons pas pouvoir l'intégrer (entre l'exigence de --expose-internals et l'absence d'un bon moyen d'obtenir sa sortie par programme); J'ai constaté que cela fonctionne si vous suivez quelques étapes:

• lancez Mocha avec --expose-internals ( node --expose-internals node_modules/mocha/bin/_mocha )
• faire en sorte que votre premier fichier de test (par exemple répertorié dans mocha.opts ) contienne (ou au moins commence par) after(require('why-is-node-running'))

... donc c'est mieux que rien (même si je vais voir si je peux mettre à jour les notes de publication pour décrire cela plus en détail), mais si quelqu'un connaît une meilleure option, veuillez nous le faire savoir!

Nous sommes également désolés d'avoir manqué la documentation du site - nous la mettrons à jour dès que possible. (Une fois que # 2987 est terminé, nous pouvons même en faire une partie automatique de notre script de version / publication!)

@ScottFreeCode

borisov<strong i="7">@glossy</strong>:~/test/mocha $ node --version
v6.11.3

borisov<strong i="8">@glossy</strong>:~/test/mocha $ ./node_modules/.bin/mocha --version
4.0.0

borisov<strong i="9">@glossy</strong>:~/test/mocha $ ./node_modules/.bin/mocha --expose-internals test.spec.js 
  error: unknown option `--expose-internals'

Éditer:

Cela marche:

node --expose-internals ./node_modules/.bin/mocha test.spec.js

Bon, désolé, je n'ai pas été clair à ce sujet - --expose-internals est une option Node qui peut être utilisée en exécutant node --expose-internals ./node_modules/mocha/bin/_mocha au lieu de ./node_modules/.bin/mocha . C'est aussi quelque chose que nous pouvons corriger, puisque Mocha transmet certains indicateurs à Node et nous pouvons ajouter --expose-internals à ces indicateurs.

Création de mochajs / mochajs.github.io # 81 et # 3045 pour suivre la mise à jour de la documentation et des indicateurs de nœud de Mocha, respectivement. Gardera ce problème ouvert au moins jusqu'à ce que la documentation soit mise à jour.

@ScottFreeCode, vous voudrez peut-être mentionner que --expose-internals ne fonctionne que pour le nœud <= 6. Espérons que les gens peuvent rétrograder temporairement vers le nœud 6 afin de trouver quel minuteur doit être annulé ou non référencé , ou les sockets devant être unref 'ed. Vous pouvez également diriger les gens vers les hooks after et afterEach pour effectuer le nettoyage.

(y a-t-il un hook global "après" que mocha appelle lorsque tous les tests sont terminés?)

Dans tous les cas, j'apprécie l'aide et merci pour Mocha!

vous pouvez mentionner que --expose-internals ne fonctionne que pour le nœud <= 6.

Êtes-vous sûr? J'ai testé avec Node 8.6.0. Bien que ce ne soit pas sur tous les systèmes d'exploitation, je suppose que je devrais allumer toutes les boîtes que j'ai et vérifier trois fois ...

Voici un résumé avec un guide approximatif pour contourner ce problème pour le moment.

Êtes-vous sûr? J'ai testé avec Node 8.6.0. Bien que ce ne soit pas sur tous les systèmes d'exploitation, je suppose que je devrais allumer toutes les boîtes que j'ai et vérifier trois fois ...

Cela "fonctionne" en ce sens qu'il déclenche la sortie du module, mais cela ne me donne pas beaucoup d'informations, quelle que soit la version de Node.js.

Je vais ajouter quelques mises à jour au site, mais s'il vous plaît voir mes prochains commentaires sur # 3045.

Cela "fonctionne" en ce sens qu'il déclenche la sortie du module, mais cela ne me donne pas beaucoup d'informations, quelle que soit la version de Node.js.

Cela donne un stacktrace utile pour setTimeout et setImmediate , mais aucune information réelle pour d'autres choses comme un serveur d'écoute (comme je viens de le découvrir en essayant de comprendre comment il fait ce qu'il fait. Faire). L'exemple "async-dump" dans l'essentiel a un réel avantage en termes de fonctionnement pour tout (et ne nécessitant pas --expose-internals ), même s'il n'est utilisable que sur les versions plus récentes de Node.

Je suppose que mon conseil général serait "si vous vous arrachez les cheveux, ajoutez simplement --exit et détendez-vous". Alors ne l'utilisez pas pour votre prochain projet: wink:

... et voici les docs

Désolé de commenter à nouveau le PR fermé, mais il pourrait y avoir une solution conviviale ici:

On pourrait enregistrer un avertissement sur le comportement modifié après que le coureur ait terminé pendant 3 secondes environ, mais le processus ne s'est pas terminé.
Il faudrait juste ajouter un setTimeout() après que le coureur ait terminé et appeler timeout.unref () pour s'assurer que ce délai n'empêche pas le processus de se terminer. Si le délai d'expiration est exécuté, il est temps pour un avertissement 😉

J'ai pensé à cela mais je crains que cela ne cause d'autres problèmes avec les journalistes ou d'autres intégrations ... Je ne peux pas prouver que ce ne sera pas le cas.

Si vous rencontrez toujours des problèmes et que why-is-node-running ne fonctionne pas correctement, consultez wtfnode .

Ce package fonctionnait beaucoup mieux pour moi.

Je peux voir à quel point le fait d'arrêter soudainement la sortie des tests existants peut être déconcertant (c'est le moins qu'on puisse dire). Je vois une mention sur le nouveau comportement dans les notes de publication .

J'ai découvert le changement par accident moi-même avec de nouveaux tests qui m'ont obligé à m'assurer que j'appelais redis.quit () dans une fonction after () et je suis définitivement satisfait du nouveau comportement, qui me semble correct et approprié.

Je n'ai pas eu besoin d'utiliser [cet essentiel] cette fois, mais comme déjà mentionné par @boneskull , il semble que cela pourrait être vraiment utile quand on ne sait pas quelles tâches asynchrones ne sont pas terminées et

Je dois admettre que je ne comprends pas tout à fait les enjeux des tickets référencés qui se cachent derrière ce nouveau changement de comportement.

AFAICT, cela a quelque chose à voir avec les rejets de promesses non gérés. Mais pardonnez-moi, si vous ne résolvez pas une promesse donnée à un test Mocha, alors Mocha ne réussira ni ne continuera (si --bail est défini) à partir de ce test, non? Il doit donc s'agir d'une Promise imbriquée mal implémentée qui n'a pas de gestionnaire de rejet, mais le code contenant doit quand même être résolu.

Si tel est le cas, je ne vois pas comment c'est le travail de Mocha de détecter ces problèmes. Et si vous implémentez de la magie pour détecter ces problèmes, ce qui peut rendre les tests actuels (correctement écrits) indéfiniment bloqués, alors cette magie devrait être un comportement opt-in , pas un opt-out - c'est --no-exit plutôt que --exit .

Je regarde tous mes tests en utilisant le pilote officiel node-mongodb-native suspendu parce que ce pilote regroupe les connexions et ne les ferme pas toutes sur .close() , apparemment être design. Mes tests se comportent correctement, mais une dépendance ne l'est pas (ou est-ce? Je ne sais pas nécessairement pour un fait que c'est un mauvais comportement d'avoir des sockets ou des descripteurs de fichiers persistants jusqu'à ce qu'un script soit quitté ailleurs - n'est-ce pas?). Alors qu'est-ce que je teste ici? Mon code ou celui de quelqu'un d'autre? Je pensais que je testais le mien, mais apparemment pas.

Bien sûr, je peux ajouter le drapeau --exit , mais le prochain gars pourrait ne pas le faire, et dans tous les cas, il semble juste que je puisse écrire des tests parfaitement fins avec un code parfaitement fin en cours de test, et avoir toujours une cause de dépendance aléatoire mes tests à accrocher indéfiniment.

Si j'ajoute un process.exit() dans un dernier crochet after() , mes tests ne se bloqueront pas, mais alors cela cassera horriblement avec --watch (éventuellement d'autres fonctionnalités), non seulement m'empêchant de surveiller les changements, mais m'éjectant dans une coque sans curseur.

Il se peut très bien que je sois le plus ignorant ici (certainement il y a beaucoup de choses que je ne reçois pas, et beaucoup de gens ont été impliqués, alors j'aurais tendance à le penser :)), je me sens juste comme tout ça la chose n'est pas tout à fait ... non ...?

À votre santé :)

EDIT: Compte tenu de ce comportement, y a-t-il un moyen pour moi de vérifier à l'intérieur d'un test Mocha s'il est exécuté avec --watch afin que je puisse m'assurer de ne pas appeler process.exit() et casser des choses?

@DanielSmedegaardBuus TL; DR sur la solution: mettez --exit dans le fichier mocha.opts . (C'est généralement la solution pour tout ce qui doit toujours être défini lorsque Mocha est exécuté, en guise d'astuce plus générale.) Clarification plus détaillée de l'objet de ce changement: ci-dessous.

2640 concerne les rejets de promesses, n'est pas destiné à faire quoi que ce soit mais à les rendre cohérents avec les exceptions synchrones lancées à partir d'un code de test asynchrone non promis, et n'a pas encore été implémenté .

Il s'agit de tests mettant en place des ressources, des écouteurs ou du travail en cours et non de le nettoyer, que des promesses soient utilisées dans leur mise en œuvre et / ou dans le test. Par exemple:

J'ai un test pour une API basée sur des websockets, qui comprend l'ouverture et la fermeture des connexions. Cette API était boguée et ne fermait pas correctement les connexions, mais a réussi mes tests car les tests n'avaient pas vraiment de moyen d'affirmer que la connexion sous-jacente était traitée correctement. (Si j'avais strictement testé uniquement mon propre code, j'aurais pu vérifier qu'il utilise la dépendance dans ce que je pensais à tort être la bonne manière; je testais avec le vrai websocket précisément pour détecter les problèmes d'exactitude d'utilisation en premier lieu cependant - tests d'intégration pour compléter les tests unitaires.) J'ai attrapé cette erreur lorsque je suis passé au comportement --no-exit (de Mocha 3; maintenant la valeur par défaut dans Mocha 4) et j'ai découvert que si j'exécutais ces tests, Node ne se fermerait pas car la connexion websocket est toujours à l'écoute.

(Il est vrai qu'il est possible que l'erreur réside dans une dépendance plutôt que dans votre propre code, mais même dans ce cas, il peut être utile de savoir qu'avant de livrer une version donnée de cette dépendance - comme évoqué ci-dessus, c'est plus applicable pour les tests d'intégration en premier lieu que pour les tests unitaires, mais idéalement, un projet a les deux.)

Ce n'est pas toujours nécessaire, bien sûr - dans certains cas, une ressource de cette nature peut être destinée à être laissée en vie jusqu'à ce que le processus soit tué, ou peut garder Node en vie même si aucun autre nettoyage de la ressource n'a vraiment d'importance, ou peut faire partie d'un pool de ressources qui réutilise des membres individuels et n'a pas besoin de nettoyer le pool dans son ensemble - dans ce cas, --exit serait correct . La raison du changement du comportement par défaut était d'augmenter la visibilité de ces problèmes: avant, vous ne sauriez probablement jamais essayer --no-exit et vérifier ces types d'erreurs, maintenant vous les rencontrerez par défaut et peut --exit si vous déterminez que le comportement est correct (ou du moins ne vaut pas la peine de s'inquiéter).

Il y a, bien sûr, quelque chose d'un problème avec le «correctif» qui se bloquer lorsque cela se produit n'est pas très informatif . Nous devons encore déterminer si nous pouvons intégrer un moyen de vérifier par programme les choses toujours en cours d'exécution (afin qu'un avertissement ou une erreur approprié puisse être donné) qui fonctionnera sur toutes les versions prises en charge de Node sans interférer avec tout ce qui pourrait encore être nettoyage ou fermeture lorsque Mocha atteint la fin.

Je suis désolé, mais c'était très frustrant. J'essayais juste de savoir pourquoi le moka ne sort pas. https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit liens vers why-is-node-running , alors maintenant je suis parti, j'ai essayé d'utiliser ce module, j'ai vu un message cryptique "Erreur: module introuvable ' internal / linkedlist '... (stack trace) ", et après avoir suivi le terrier du lapin en essayant de découvrir pourquoi --expose-internals ne fonctionne pas, je me retrouve à https://github.com/mochajs/mocha/ issues / 3045 pour trouver une solution supposée, mais why-is-node-running me dit qu'il y a 1 handle connu le gardant ouvert, et quelques poignées inconnues, mais ne liste rien.

Ce n'est peut-être pas le bon endroit pour en parler, mais la documentation de mocha ne devrait pas recommander des solutions qui nécessitent autant de recherches sur Google et de problèmes de plongée pour se mettre au travail . J'essayais de retirer des choses et de les ajouter, avec un comportement très incohérent. Pour le bien des futurs utilisateurs et de ma santé mentale:

package.json:

"scripts": {
    "test": "mocha --exit"
}

C'est le mieux que je puisse faire.

@jeffvandyke Je comprends votre frustration et j'ai vécu les mêmes problèmes - mais si vous avez des affirmations derrière des promesses, vous apprécierez peut-être ce changement.

J'avais un certain nombre de spécifications qui avaient un comportement asynchrone irrégulier. En fonction de l'ordre d'exécution de mes spécifications, les erreurs de rejet de promesse non interceptées seraient consignées dans la console, puis défilées hors de vue par des centaines d'autres tests qui ont réussi, ou l'instance de nœud s'arrêterait avant le rejet.

Après avoir supprimé le --exit de mon mocha.opts , les promesses rejetées consignaient de manière fiable les erreurs et mettraient en évidence ces bogues.

Je sais, beaucoup de douleur partagée :) Le comportement documenté de Mocha me semble en fait correct, mais même si mes 5 tests semblent assez simples, il suffit d'utiliser node-fetch pour tester une api, je ne sais toujours pas pourquoi mocha ne se ferme pas , même s'ils réussissent tous (oui, ils peuvent également échouer). Je pourrais passer plus de temps à essayer de comprendre pourquoi why-is-node-running ne fonctionne pas, mais je suis fatigué de miser sur le code des autres, alors je pense que je vais me donner une pause pour le moment.

Je vais probablement continuer à jouer avec, et si je peux obtenir quelque chose de reproductible, je pourrais peut-être ouvrir un nouveau numéro, sans promesse cependant.

recommande le débogueur du nouvel inspecteur de nœuds ... il a de bonnes traces asynchrones.

Yay! Il s'avère que wtfnode est bien meilleur pour faire la lumière à ce sujet. J'ai découvert que lors de l'utilisation de node-fetch, je dois appeler result.text() ou .json() ou la connexion reste ouverte. Lancer wtfnode ./node_modules/.bin/_mocha et appuyer sur Ctrl-C a révélé les connexions ouvertes.

Je pense que cela aurait été plus facile si la documentation recommandait ce package plutôt que why-is-node-running .

Une autre suggestion: j'aime vraiment l'idée de @andywer d'avoir une sorte d'avertissement si le moka ne sort pas. Ce serait bien si mocha pouvait même utiliser wtfnode pour lister les poignées actives gardant le nœud en vie après un certain temps.

Quelle que soit la bonne chose à faire, je pense que c'est une poubelle que j'ai dû chercher si loin pour comprendre pourquoi le moka ne sortirait pas. Bref, j'ai donné mes suggestions :)

Salut les gars,
Je pense que cette fonctionnalité ne fonctionne toujours pas correctement, c'est le test --no-exit est une excellente option par défaut et je suis tout à fait pour, mais soit je n'arrive pas à comprendre ce que je fais mal ou quelque chose ne va pas intrinsèquement avec moka et cela empêche de fermer même les tests les plus simples.

describe('describe', function() { it('it', function(done) { done(); }); });

résumé: --exit fonctionne, --no-exit ne ferme aucun test.

Dans mon cas, j'utilise une application Koa et je teste avec Mocha 4 + Supertest .

Je devais juste fermer le serveur avec done appeler après les notes de publication "Pour éviter les faux positifs et encourager de meilleures pratiques de test".

Avant:

request(app.listen())
  .post('/')
  .send(requestSrc)
  .expect({ f: {} }, done)

Après:

const server = app.listen()

request(server)
  .post('/')
  .send(requestSrc)
  .expect({ f: {} }, () => {
    server.close()
    done()
  })

J'espère que cela aide somenoe.

Je fais du bootstrap pour moka avant chaque test. Fondamentalement, démarrer un petit serveur HTTP dans le même processus.

Y a-t-il un événement auquel je peux m'accrocher pour l'arrêter après l'arrêt de Mocha? Je veux juste l'arrêter, mais juste à ce moment-là.

J'adore l'idée derrière cette fonctionnalité btw .. c'est un bon test pour voir si vous avez des événements en suspens.

@evert Cela ne fonctionne pas en fermant le serveur dans after ?

Y a-t-il un «après tout» global qui s'exécute après que le moka soit fait? J'ai peut-être manqué ça! Impossible de le trouver dans la documentation.

Oui, il existe un hook global after .

https://mochajs.org/#root -level-hooks

Je vous remercie! J'ai manqué ça, désolé: / je ne connaissais pas les termes pour ctrl-f.

wtfnode n'a pas vraiment fonctionné pour moi. Tout ce que j'ai pu voir, c'est qu'un PID commencé par du moka était suspendu.

D'autre part, @boneskull a fonctionné: https://github.com/mochajs/mocha/issues/3044#issuecomment -351299745. Je vous remercie!

wtfnode doit être exécuté sur _mocha , pas sur mocha .

Merci pour le --exit . Il l'a corrigé pour moi.

entrez ce script dans package.json:
"scripts": {
"test": "moka --exit"
}

J'ai essayé divers remèdes mentionnés dans ce fil:

• Why-is-node-running ne produit aucune sortie
• wtfnode produit une sortie mais pas assez pour déterminer où les descripteurs de fichier / Sockets / Serveurs / Timers sont créés dans le code
• erreurs de méthode de débogage async_hooks
• l'ajout de –exit à l'indicateur de ligne moka cmd entraîne la sortie

Alors suivez @ProfJigsaw et utilisez –exit, c'est ce que je fais. Ce serait bien s'il y avait une amélioration par moka, au moins un moyen de déterminer où se trouvent les problèmes et comment les résoudre.

C'est à ça que sert un débogueur, IMO. Comment débogueriez-vous vos propres scripts s'ils ne se terminaient jamais?

https://github.com/GoogleChromeLabs/ndb est un projet sympa.

Hors sujet: j'adore ce billet, juste pour les informations sur les outils de dépannage qu'il continue de donner! :)

@borisovg Imaginez à quel point ce ticket serait génial s'il fournissait réellement une solution! :)
@boneskull Existe-t-il une fonction de

@mjgs cela a fonctionné pour moi - wtfnode fonctionné mais seulement quand je l'ai utilisé avec le binaire _mocha , pas le mocha un:

$ wtfnode ./node_modules/.bin/_mocha my-shitty-code.spec.js 


  tests
    ✓ some test


  1 passing (5ms)

^C[WTF Node?] open handles:
- File descriptors: (note: stdio always exists)
  - fd 1 (tty) (stdio)
  - fd 2 (tty) (stdio)
- Servers:
  - :::8080 (HTTP)
    - Listeners:
      - request: (anonymous) @ /home/borisov/test/my-shitty-code.js:4
- Intervals:
  - (5000 ~ 5 s) (anonymous) @ /home/borisov/test/my-shitty-code.js:8

@borisovg Merci pour votre super exemple. Dans mon cas, wtfnode montre qu'il y a une connexion mongo ouverte, mais toutes les connexions mongo dans mon my-shitty-code.js ont été fermées, donc le problème vient d'ailleurs, et wtfnode ne donne pas assez d'informations sur où il se trouve de.

Si wtfnode indique qu'une connexion mongo db est ouverte, alors elle est ouverte. Pourquoi supposeriez-vous que c'est faux?

@evert je pense que vous avez peut-être mal interprété ce que j'ai écrit

Les exemples minimaux sont parfaits pour l'illustration, et il est en fait utile de voir une sortie similaire à ce que vous voyez, mais dans le code réel qui a été écrit pendant de nombreuses années, ces connexions ne sont pas si faciles à trouver. Il est bon de savoir qu'il y a encore des connexions mongo ouvertes, mais les trouver n'est pas anodin. J'ai finalement trouvé des connexions ouvertes, mais elles étaient beaucoup plus profondes dans le code que le niveau de surface où toutes les connexions avaient été fermées de manière vérifiable, wtfnode n'a pas aidé à identifier où elles se trouvaient seulement en listant le chemin du module mangouste. J'en ai encore à retrouver, basé uniquement sur le numéro de port, mais j'ai bon espoir.

J'ai rencontré ce problème en écrivant une fonction Serverless qui communiquait avec Firebase. Il s'avère que leur SDK d'administration maintient un handle ouvert indéfiniment. En raison de ce changement (et de la suggestion subséquente d'utiliser wtfnode , j'ai pu identifier ce fait et m'épargner une tonne de maux de tête (et de coûts) sur la route.

À mon avis, il serait très utile d'inclure une sorte de logique «si elle se bloque pendant X longtemps et n'a pas de sortie, lancez du texte vers stdout». Je ne sais pas dans quelle mesure cela est faisable ou quelle quantité de bande passante est disponible pour produire une telle amélioration, mais je pense que cela pourrait aider à atténuer la frustration initiale de "wtf continue avec mon moka!"

var timers = sinon.useFakeTimers({
    now: new Date().getTime(),
    shouldAdvanceTime: true,
});

Si j'oublie timers.restore(); le processus se bloque pour toujours.

Sur la base de la documentation @pgilad envoyée ici, il existe pour moi une solution plus propre. Comme le dit la documentaion :

Pour éviter les faux positifs et encourager de meilleures pratiques de test, Mocha ne se tuera plus automatiquement via process.exit () quand il pense qu'il devrait être exécuté.

Une solution plus propre alors ce serait de créer une fonction globale after (une fonction after dehors de toute fonction describe ), je recommanderais dans un fichier séparé comme exit-mocha.js ou exit-mocha si vous voulez. Le rappel envoyé à après que vous puissiez forcer une sortie de processus de nœud qui va se terminer sans aucune erreur. Le fichier peut être envoyé à mocha cli comme s'il s'agissait d'un autre fichier de test (il pourrait simuler un drapeau --exit )

exit-mocha.js ou exit-mocha

after('Exit mocha gracefully after finishing all tests execution'. function () {
  // Exit node process
  process.exit();
});

Ensuite, vous pouvez exécuter des tests moka comme:

mocha exit-mocha test/**/*.spec.js

ou

mocha exit-mocha.js test/**/*.spec.js

Il est important que si vous utilisez des caractères génériques pour le nom des fichiers de test comme je l'ai fait avec test/**/*.spec.js que le nom du fichier exit-mocha ne corresponde PAS au modèle de caractères génériques, sinon, il ne sera pas être possible pour vous de l'utiliser comme un "drapeau"

@ vctr90 C'est une excellente solution, bien que vous ayez un point où vous devriez avoir une virgule dans votre exemple. De plus, le tout peut être codé simplement:

after('Exit mocha gracefully after finishing all tests execution', process.exit);

Y a-t-il une chance qu'un développeur explique pourquoi l'ajout de cela à Mocha proprement dit blesserait quelqu'un (car cela aiderait clairement beaucoup de gens)?

@machineghost J'aime le nouveau comportement pour 2 raisons:

1. Presque aucune autre bibliothèque ne se fermera après avoir «terminé son travail». Par exemple, la fermeture d'un serveur Node TCP ne déclenchera pas automatiquement une sortie. De cette façon, il est cohérent avec les autres bibliothèques.
2. Si le nœud ne se ferme pas, cela signifie qu'il y a des événements en attente de résolution. Il est probablement préférable d'essayer d'améliorer votre code pour que les choses soient nettoyées après chaque test. Cela pourrait également suggérer qu'il y a des fuites de mémoire.

Donc, quand je rencontre cela, c'est une incitation pour moi à essayer de nettoyer mon code pour que cela ne se produise pas.

Votre point de vue à ce sujet pourrait être «je ne me soucie pas des fuites de mémoire», ou «cela ne vaut pas la peine d'être corrigé dans mon application». Si vous êtes dans cette catégorie, le plus simple est de faire un mocha.opts et d'ajouter --exit .

Il me semble juste qu'il s'agit de faire plus de bruit, pas de signal: dans la grande majorité des cas, personne ne va s'améliorer parce que Mocha s'est accroché à la fin.

Si Mocha va par défaut, il semble qu'il devrait se terminer par défaut lorsque les tests (et tous les appels after / afterEach ) sont terminés. Ne pas le faire juste pour dire aux gens "que votre environnement de test artificiel est artificiel" ne profite pas à la majorité (ou même à une minorité décente) des utilisateurs.

Si les gens veulent vraiment déboguer les connexions non fermées, il semble que ce soit le cas pour

Pour le dire autrement, si vous voulez dire à 99% des personnes qui se heurtent à ce "utilisez simplement --exit ", alors peut-être que --exit ne devrait pas être une option spéciale que vous devez fournir ... peut-être que le comportement par défaut devrait être de servir 99% des cas d'utilisateurs (tout en donnant bien sûr aux utilisateurs l'option de --tell-me-if-I-have-unclosed-stuff-in-my-testing-environment-and-that-is-actually-what-i-am-trying-to-find-out )?

Je veux dire, si vous en faisiez l'option, à quelle fréquence pensez-vous que les gens la passeraient même?

PS Je viens de tomber sur ceci: https://stackoverflow.com/questions/54999115/where-to-destroy-knex-connection. Si vous regardez la deuxième réponse, ce comportement dans Mocha a directement amené au moins un utilisateur (qui n'est pas moi, et je jure que je ne le connais pas: je viens de trouver cela par chance après avoir fait mon dernier message) à ajouter incorrect code non-test (cette "fonctionnalité" leur a fait penser à tort qu'il fallait appeler knex.destroy() dans leur application).

Version récapitulative:

Nice Person: Vous n'avez probablement généralement pas besoin d'appeler explicitement knex.destroy () - cela est impliqué par la documentation elle-même disant (c'est moi qui souligne):

Nice Person: cite des documents

Personne confuse: Si je n'appelle pas knex.destroy (), mon script se bloque. Alors qu'est-ce que cela signifie que nous n'avons pas besoin d'appeler explicitement knex.destroy ()

Nice Person: Ah, vous avez seulement mentionné ailleurs que c'est pour Mocha. Pour les utilisations régulières du serveur, vous n'avez pas besoin de détruire le pool de connexions - pour Mocha, vous voudrez peut-être examiner un hook de démontage global, voir futurestud.io/tutorials/...

Mais pour être clair, cet utilisateur avait un environnement de travail, et parce que Mocha leur a (essentiellement) dit que leur code parfaitement bon était faux, ils ont perdu qui sait combien de temps à essayer de résoudre le bogue qu'ils ont créé en détruisant leurs connexions. Et c'est juste cette personne malchanceuse qui a fait ça en public, et que j'ai vu.

Donc, je suppose que ce que je suis en train de transmettre est, ce n'est pas seulement sur ce qui est philosophiquement correct, ni juste que certains bruits obscurcit signaux utiles ... ce comportement est réellement la cause du

Je suis désolé, j'ai pris votre point fatigué pour une question honnête. Je regrette d'avoir répondu. Peut-être que les développeurs peuvent verrouiller ce fil.

"mocha --reporter mocha-allure-reporter ./tests/controllers --exit" fonctionné pour moi. En effet, le --exit est une très bonne solution de contournement. J'utilise la version 5.2.0 dans mon projet.

Existe-t-il un moyen d'obtenir l'effet équivalent de l'utilisation de l'indicateur --exit lors de l'utilisation de moka "par programme ?"

Je ne vois pas d'option documentée pour exit / noexit, ni de moyen général de transmettre une chaîne d'indicateur lors de l'utilisation de l'API NodeJS.

En suivant le schéma des autres options, j'ai essayé:

const mocha = new Mocha({
    exit: true,
});

mais n’a pas pu obtenir l’effet souhaité.

Une inspection cursive de https://github.com/mochajs/mocha/blob/master/lib/mocha.js semble montrer que cette option doit être ajoutée non seulement à la documentation, mais aussi à la source.

En plus de fournir une solution rapide (utilisez --exit ), je suis d'accord qu'ils ont laissé à l'utilisateur le problème central de la recherche des tests défectueux. J'ai du mal avec cela moi-même maintenant, mais lors de la mise à niveau des versions majeures, je m'assure de lire les notes de publication et de ne pas mettre à niveau aveuglément

Comment le passez-vous exactement? Ceci est mon script package.json

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } et cela ne fonctionne pas

En plus de fournir une solution rapide (utilisez --exit ), je suis d'accord qu'ils ont laissé à l'utilisateur le problème central de la recherche des tests défectueux. J'ai du mal avec cela moi-même maintenant, mais lors de la mise à niveau des versions majeures, je m'assure de lire les notes de publication et de ne pas mettre à niveau aveuglément

Comment le passez-vous exactement? Ceci est mon script package.json

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } et cela ne fonctionne pas

Eu le même problème et je pense que je ne suis pas le seul. Je devais juste bouger - sortir à la fin.
Cela n'a pas fonctionné:
istanbul cover ./node_modules/mocha/bin/_mocha --exit - test / .test.jsCela m'a fonctionné:istanbul cover ./node_modules/mocha/bin/_mocha - test / .test.js --exit

exit ne fait rien lors de l'exécution de Mocha par programme, fwiw. le processus est quitté de force par le wrapper CLI, et non par Mocha-the-library.