Veo exactamente el mismo problema. Las pruebas pasarán y luego el moka simplemente cuelga. Ver mi Travis CI:
https://travis-ci.org/mkrufky/node-dvbtee/builds/282593109

También noté este mismo problema en video-dev / hls.js: mocha simplemente se cuelga después de pasar las pruebas:
https://travis-ci.org/video-dev/hls.js/builds/282590422

¿Habéis leído las notas de la versión? https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit

Gracias. tok bad el sitio web de mocha no se actualiza con este cambio importante. Los cli args no lo mencionan.

Además de proporcionar una solución rápida (use --exit ), estoy de acuerdo en que dejaron el problema principal de encontrar las pruebas defectuosas al usuario. Yo mismo estoy luchando con eso ahora, pero cuando actualizo las versiones principales, me aseguro de leer las notas de la versión y no actualizar a ciegas

Las notas de la versión sugieren usar why-is-node-running excepto que no funciona debido a https://github.com/mafintosh/why-is-node-running/issues/7

Golpeado por esto también. Entiendo el razonamiento detrás del cambio al predeterminado y gracias por incrementar la versión principal, pero dado que why-is-node-running está abandonado y roto, este puede no ser el cambio más fácil de usar.

Hola a todos,

En primer lugar, quiero disculparme por la ruta de actualización aproximada en este punto; definitivamente estamos de acuerdo en que Mocha debería decirle al usuario qué mantiene las pruebas en ejecución (y luego ni siquiera necesitaría mantener el proceso abierto; podría ser una razón para devolver el error después de que hayan terminado), pero aún no he encontrado una manera completamente satisfactoria de hacerlo. La versión 4 no obtuvo la cantidad de tiempo que queríamos dedicarle, ya que nuestro CI falló debido a cambios en el instalador de PhantomJS 1.x (package-lock.json probablemente habría evitado esto si hubiéramos tenido se configuró de antemano, pero todavía no podemos hacerlo funcionar ). why-is-node-running fue la única herramienta que encontramos para ayudar, pero no creemos que podamos integrarla (entre el requisito de --expose-internals y la falta de una buena manera de obtener su salida mediante programación); Descubrí que funciona si sigues un par de pasos:

• ejecutar Mocha con --expose-internals ( node --expose-internals node_modules/mocha/bin/_mocha )
• hacer que su primer archivo de prueba (por ejemplo, que aparece en mocha.opts ) contenga (o al menos comience con) after(require('why-is-node-running'))

... así que es mejor que nada (aunque veré si puedo actualizar las notas de la versión para describir esto con más detalle), pero si alguien conoce una opción mejor, ¡háganoslo saber!

También lamento perder la documentación del sitio; la actualizaremos lo antes posible. (Una vez que el # 2987 esté listo, ¡incluso podemos convertirlo en una parte automática de nuestra versión / publicación de secuencias de comandos!)

@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'

Editar:

Esto funciona:

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

Bien, lo siento, no estaba claro al respecto: --expose-internals es una opción de nodo que se puede usar ejecutando node --expose-internals ./node_modules/mocha/bin/_mocha lugar de ./node_modules/.bin/mocha . Eso también es algo que podemos arreglar, ya que Mocha pasa ciertas banderas a Node y podemos agregar --expose-internals a esas banderas.

Creó mochajs / mochajs.github.io # 81 y # 3045 para rastrear la actualización de la documentación y los indicadores de Mocha's Node, respectivamente. Mantendrá este problema abierto al menos hasta que se actualice la documentación.

@ScottFreeCode, es posible que desee mencionar que --expose-internals solo funciona para el nodo <= 6. Con suerte, las personas pueden degradar al nodo 6 temporalmente para que puedan encontrar qué temporizador debe cancelarse o qué sockets deben ser unref 'ed. También puede indicarle a la gente los ganchos after y afterEach para hacer la limpieza.

(¿Hay un gancho "después" global que llama mocha cuando se completan todas las pruebas?)

En cualquier caso, agradezco la ayuda y gracias por Mocha!

es posible que desee mencionar que --expose-internals solo funciona para node <= 6.

¿Estás seguro? Probé con Node 8.6.0. Aunque no en todos los sistemas operativos, supongo que debería activar cada caja que tengo y verificar tres veces ...

Aquí hay una esencia con una guía aproximada para solucionar esto por el momento.

¿Estás seguro? Probé con Node 8.6.0. Aunque no en todos los sistemas operativos, supongo que debería activar cada caja que tengo y verificar tres veces ...

Esto "funciona" porque activa la salida del módulo, pero en realidad no me da mucha información, independientemente de la versión de Node.js.

Voy a agregar algunas actualizaciones al sitio, pero por favor vea mis próximos comentarios sobre # 3045.

Esto "funciona" porque activa la salida del módulo, pero en realidad no me da mucha información, independientemente de la versión de Node.js.

Proporciona un seguimiento de pila útil para setTimeout y setImmediate , pero no hay información real para otras cosas, como un servidor de escucha (como descubrí recientemente al tratar de entender cómo está haciendo lo que haciendo). El ejemplo "async-dump" en la esencia tiene una ventaja real en términos de trabajar para todo (y no requiere --expose-internals ), aunque solo se puede usar en versiones más nuevas de Node.

Supongo que mi consejo general sería "si te estás arrancando los pelos, añade --exit y relájate". Entonces no lo use para su próximo proyecto: wink:

... y aquí están los documentos

Lamento volver a comentar sobre el PR cerrado, pero podría haber una solución fácil de usar aquí:

Se podría registrar una advertencia sobre el comportamiento cambiado después de que el corredor haya terminado durante aproximadamente 3 segundos, pero el proceso no terminó.
Solo necesitaría agregar setTimeout() después de que el corredor haya terminado y llamar a timeout.unref () para asegurarse de que este tiempo de espera no impida que el proceso salga. Si se ejecuta el tiempo de espera, es hora de una advertencia 😉

Lo he considerado, pero desconfío de que cause otros problemas con los reporteros u otras integraciones ... No puedo probar que no lo hará.

Si aún tiene problemas y why-is-node-running no funciona correctamente, consulte wtfnode .

Ese paquete funcionó mucho mejor para mí.

Puedo ver cómo hacer que las pruebas existentes dejen de salir repentinamente puede ser desconcertante (por decir lo menos). Veo una mención sobre el nuevo comportamiento en las notas de la

Descubrí el cambio accidentalmente yo mismo con nuevas pruebas que me obligaron a asegurarme de que llamé a redis.quit () en una función after () y definitivamente estoy satisfecho con el nuevo comportamiento, que me parece correcto y apropiado.

No necesitaba usar [esta esencia] esta vez, pero como ya lo mencionó @boneskull , parece que podría ser realmente útil cuando no está claro qué tareas asincrónicas no se han completado y están impidiendo que el proceso salga.

Debo admitir que no entiendo del todo los problemas en los tickets de referencia que se encuentran detrás de este nuevo cambio de comportamiento.

AFAICT, tiene algo que ver con los rechazos de Promesa no manejados. Pero perdóneme, si no resuelve una Promesa dada a una prueba de Mocha, entonces Mocha no tendrá éxito ni continuará (si se establece --bail ) de esa prueba, ¿verdad? Por lo tanto, debe ser una Promise anidada mal implementada que no tiene un controlador de rechazo, pero el código que lo contiene debe resolverse de todos modos.

Si este es el caso, no veo cómo es el trabajo de Mocha detectar esos problemas. Y si implementa algo de magia para detectar esos problemas, lo que puede hacer que las pruebas actuales (escritas correctamente) se cuelguen indefinidamente, entonces esa magia debería ser un comportamiento de suscripción voluntaria, no de exclusión voluntaria , es decir, --no-exit lugar de --exit .

Estoy viendo todas mis pruebas usando el controlador oficial node-mongodb-native colgando porque ese controlador .close() , aparentemente por diseño. Mis pruebas se están comportando correctamente, pero una dependencia no (¿o no? No sé necesariamente a ciencia cierta que es un mal comportamiento tener sockets persistentes o descriptores de archivo hasta que se sale de un script en otro lugar, ¿verdad?). Entonces, ¿qué estoy probando aquí? ¿Mi código o el de otra persona? Pensé que estaba probando el mío, pero aparentemente no.

Claro, puedo agregar la bandera --exit , pero es posible que el siguiente no lo haga, y de cualquier manera, parece incorrecto que pueda escribir pruebas perfectamente finas con un código perfectamente bueno que se está probando, y todavía tengo alguna causa de dependencia aleatoria mis pruebas para colgar indefinidamente.

Si agrego un process.exit() en un gancho final after() , mis pruebas no se bloquearán, pero luego se romperán horriblemente con --watch (posiblemente otras características), no solo impidiéndome observar los cambios, pero expulsándome a un caparazón sin cursor.

Es muy posible que yo sea el que no tiene ni idea aquí (ciertamente hay muchas cosas que no entiendo, y mucha gente se ha involucrado, así que tendería a pensar que sí :)), siento que todo esto la cosa no está del todo ... ¿verdad ...?

Salud :)

EDITAR: Dado este comportamiento, ¿hay alguna forma de verificar dentro de una prueba de Mocha si se está ejecutando con --watch para poder asegurarme de no llamar a process.exit() y romper cosas?

@DanielSmedegaardBuus TL; DR en la solución: ponga --exit en el archivo mocha.opts . (Esta suele ser la solución para cualquier cosa que deba configurarse siempre cuando se ejecuta Mocha, como un consejo más general). Aclaración más detallada de qué se trata este cambio: a continuación.

2640 trata sobre el rechazo de promesas, no tiene la intención de hacer nada más que hacerlos consistentes con las excepciones sincrónicas lanzadas desde el código de prueba asincrónico sin promesas, y aún no se ha implementado .

Se trata de pruebas que configuran recursos, oyentes o trabajo continuo y no lo limpian, independientemente de si las promesas se utilizan en su implementación y / o en la prueba. Por ejemplo:

Tengo una prueba para una API basada en websockets, que incluye abrir y cerrar conexiones. Esta API tenía errores y no cerraba las conexiones correctamente, pero pasó mis pruebas ya que las pruebas realmente no tenían una forma de afirmar que la conexión subyacente se trató correctamente. (Si hubiera probado estrictamente solo mi propio código, podría haber verificado que está usando la dependencia en lo que pensé erróneamente --no-exit (de Mocha 3; ahora el predeterminado en Mocha 4) y descubrí que si ejecutaba esas pruebas, Node no se cerraría porque la conexión websocket todavía está escuchando.

(Es cierto que es posible que el error se encuentre en una dependencia en lugar de en su propio código, pero incluso entonces, puede ser valioso saber que antes de enviar una versión determinada de esa dependencia, como se mencionó anteriormente, esto es más aplicable para las pruebas de integración en primer lugar que para las pruebas unitarias, pero idealmente un proyecto tiene ambos.)

Esto no siempre es necesario, por supuesto; en algunos casos, un recurso de esta naturaleza puede estar destinado a permanecer vivo hasta que se mata el proceso, o puede mantener vivo a Node aunque ninguna otra limpieza del recurso realmente importe, o podría ser parte de un grupo de recursos que reutiliza miembros individuales y no necesita limpiar el grupo como un todo; en tales casos, --exit sería correcto . El motivo del cambio del comportamiento predeterminado fue aumentar la visibilidad de tales problemas: antes, probablemente nunca sabría probar --no-exit y verificar este tipo de errores, ahora los encontrará de manera predeterminada y puede --exit si determina que el comportamiento es correcto (o al menos no vale la pena preocuparse).

Hay, por supuesto, un problema con la "solución" que simplemente colgar cuando esto sucede no es muy informativo . Todavía tenemos que averiguar si podemos integrar alguna forma de verificar de manera programática si las cosas aún se están ejecutando (para que se pueda dar una advertencia o error adecuado) que funcione en todas las versiones compatibles de Node sin interferir con nada que aún pueda estar funcionando. limpiar o cerrar cuando Mocha llega al final.

Lo siento, pero esto fue muy frustrante. Solo estaba tratando de averiguar por qué el moca no sale. https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit enlaces a why-is-node-running , así que ahora me fui, intenté usar ese módulo, vi un mensaje críptico "Error: No se puede encontrar el módulo ' internal / linkedlist '... (stack trace) ", y después de seguir la madriguera del conejo tratando de averiguar por qué --expose-internals no funciona, termino en https://github.com/mochajs/mocha/ issues / 3045 para encontrar una supuesta solución, pero why-is-node-running me dice que hay un identificador conocido que lo mantiene abierto, y algunos identificadores desconocidos, pero no enumera nada.

Puede que este no sea el lugar adecuado para hablar de esto, pero los documentos de mocha no deberían recomendar soluciones que requieran tanta búsqueda en Google y problemas de buceo para ponerse a trabajar . Estaba tratando de sacar cosas y agregarlas, con un comportamiento muy inconsistente. Por el bien de los futuros usuarios y mi cordura:

package.json:

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

Eso es lo mejor que puedo hacer.

@jeffvandyke Entiendo su frustración y pasé por los mismos problemas, pero si tiene alguna afirmación detrás de las promesas, puede apreciar este cambio.

Tenía varias especificaciones que tenían un comportamiento asincrónico inestable. Dependiendo del orden de ejecución de mis especificaciones, los errores de rechazo de promesa no detectados se registrarían en la consola y luego se desplazarían fuera de la vista por cientos de otras pruebas que pasaron, o la instancia de nodo se cerraría antes de que ocurriera el rechazo.

Después de eliminar --exit de mi mocha.opts , las promesas rechazadas registrarían errores de manera confiable y resaltarían esos errores.

Lo sé, mucho dolor compartido :) El comportamiento documentado de Mocha en realidad me suena correcto, pero aunque mis 5 pruebas parecen lo suficientemente simples, solo usando node-fetch para probar una API, todavía no estoy seguro de por qué mocha no sale a pesar de que todos pasan con éxito (sí, también pueden fallar). Podría pasar más tiempo tratando de averiguar por qué why-is-node-running no funciona, pero estoy cansado de engañarme con el código de otras personas, así que creo que me daré un respiro por ahora.

Probablemente seguiré jugando con él, y si puedo obtener algo reproducible, podría abrir un nuevo número, aunque sin promesas.

recomendaría el depurador del nuevo inspector de nodos ... tiene buenos rastreos asíncronos.

¡Hurra! Resulta que wtfnode es mucho mejor arrojando luz sobre esto. Descubrí que cuando uso node-fetch, tengo que llamar a result.text() o .json() o la conexión permanece abierta. Ejecutar wtfnode ./node_modules/.bin/_mocha y presionar Ctrl-C reveló las conexiones abiertas.

Creo que hubiera sido más fácil si los documentos recomendaran este paquete en lugar de why-is-node-running .

Otra sugerencia: me gusta mucho la idea de wtfnode alguna manera para enumerar los identificadores activos que mantienen el nodo vivo después de que haya pasado un tiempo.

Sea lo que sea lo correcto, creo que es basura que tuve que mirar tan lejos para descubrir por qué el moca no salía. De todos modos, he dado mis sugerencias :)

Hola chicos,
Creo que es posible que esta característica aún no funcione correctamente, esta es la prueba más básica que se me ocurrió y mocha aún no se cierra por sí solo. --no-exit es una excelente opción predeterminada y estoy totalmente de acuerdo, pero no entiendo lo que estoy haciendo mal o algo está intrínsecamente mal con mocha y me impide cerrar incluso las pruebas más simples.

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

resumen: --exit funciona, --no-exit nunca cierra ninguna prueba.

En mi caso, estoy usando una aplicación Koa y probando con Mocha 4 + Supertest .

Tuve que cerrar el servidor junto con done call siguiendo las notas de la versión "Para evitar falsos positivos y fomentar mejores prácticas de prueba".

Antes de:

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

Después:

const server = app.listen()

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

Espero que ayude a algo.

Estoy haciendo un bootstrapping para moka antes de cada prueba. Básicamente, iniciando un pequeño servidor HTTP en el mismo proceso.

¿Hay algún evento al que pueda conectarme para apagarlo después de que Mocha deja de funcionar? Solo quiero apagarlo, pero solo en ese momento.

Por cierto, me encanta la idea detrás de esta función ... es una buena prueba para ver si tienes eventos pendientes.

@evert ¿No funciona cerrando el servidor en after ?

¿Existe un 'después de todo' global que se ejecuta después de que se hace moka? ¡Puede que me haya perdido eso! No se pudo encontrar en los documentos.

Sí, hay after gancho

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

¡Gracias! Me perdí eso, lo siento: no sabía los términos para ctrl-f.

wtfnode realmente no funcionó para mí. Todo lo que pude ver fue que un PID iniciado por moca estaba colgando.

Por otro lado, @boneskull gist funcionó: https://github.com/mochajs/mocha/issues/3044#issuecomment -351299745. ¡Gracias!

wtfnode debe ejecutarse contra _mocha , no mocha .

Gracias por el --exit . Me lo arregló.

ingrese este script en package.json:
"guiones": {
"test": "mocha --exit"
}

Probé varios remedios mencionados en este hilo:

• why-is-node-running no produce salida
• wtfnode produce salida pero no lo suficiente para determinar dónde se crean los descriptores de archivo / sockets / servidores / temporizadores en el código
• errores del método de depuración async_hooks
• agregar –exit a la marca de línea de cmd mocha da como resultado la salida

Así que siga @ProfJigsaw y use –exit, eso es lo que estoy haciendo. Sin embargo, sería genial si hubiera una mejora de mocha, al menos una forma de averiguar dónde están los problemas y cómo resolverlos.

Para eso es un depurador, en mi opinión. ¿Cómo depuraría sus propios scripts si nunca salieran?

https://github.com/GoogleChromeLabs/ndb es un proyecto genial.

Fuera de tema: me encanta este boleto, ¡solo por la información sobre las herramientas de solución de problemas que sigue brindando! :)

@borisovg ¡ Imagínese lo bueno que sería este boleto si realmente
@boneskull ¿Hay alguna función de

@mjgs funcionó para mí - wtfnode funcionó, pero solo cuando lo usé con el binario _mocha , no el mocha uno:

$ 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 Gracias por su

Si wtfnode indica que una conexión mongo db está abierta, entonces está abierta. ¿Por qué asumirías que está mal?

@evert Creo que podrías haber malinterpretado lo que escribí

Los ejemplos mínimos son excelentes para la ilustración, y en realidad es útil ver un resultado similar al que está viendo, pero en el código real que se ha escrito durante muchos años, estas conexiones no son tan fáciles de encontrar. Es bueno saber que todavía hay conexiones mongo abiertas, pero encontrarlas no es trivial. Finalmente encontré algunas conexiones abiertas, pero eran mucho más profundas en el código que el nivel de la superficie donde todas las conexiones se habían cerrado de manera verificable, wtfnode no ayudó a identificar dónde estaban, solo que existían al enumerar la ruta del módulo mangosta. Todavía tengo algunos que rastrear, basados ​​solo en el número de puerto, pero tengo esperanzas.

Me encontré con este mismo problema al escribir una función sin servidor que se comunicaba con Firebase. Resulta que su SDK de administrador mantiene un control abierto indefinidamente. Debido a este cambio (y la posterior sugerencia de usar wtfnode , pude identificar ese hecho y ahorrarme un montón de dolores de cabeza (y costos) en el futuro.

En mi opinión, sería muy útil incluir algún tipo de lógica "si se cuelga durante X tiempo y no tiene ninguna salida, arroje algún texto a la salida estándar". No estoy seguro de cuán factible es eso o de cuánto ancho de banda hay disponible para producir tal mejora, pero creo que eso podría ayudar a aliviar la frustración inicial de "¡qué pasa con mi mocha!"

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

Si olvido timers.restore(); el proceso se bloquea para siempre.

Según la documentación que @pgilad envió aquí, para mí hay una solución más limpia. Como dice la documentación :

Para evitar falsos positivos y fomentar mejores prácticas de prueba, Mocha ya no se matará automáticamente a través de process.exit () cuando crea que debería dejar de ejecutarse.

Una solución más limpia sería crear una función after global (una función after fuera de cualquier función describe ), lo recomendaría en un archivo separado como exit-mocha.js o exit-mocha si lo desea. La devolución de llamada enviada después de que puede forzar una salida del proceso de nodo elegante que se cerrará sin ningún error. El archivo se puede enviar a mocha cli como si fuera otro archivo de prueba (podría simular una bandera --exit )

exit-mocha.js o exit-mocha

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

Entonces puedes ejecutar pruebas de moca como:

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

o

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

Es importante que si está usando comodines para el nombre de los archivos de prueba como hice con test/**/*.spec.js que el nombre del archivo exit-mocha NO coincida con el patrón de comodines, de lo contrario, no lo hará ser posible que lo utilice como una "bandera"

@ vctr90 Esa es una gran solución, aunque tiene un punto en el que debería tener una coma en su ejemplo. Además, todo se puede codificar en código para solo:

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

¿Existe alguna posibilidad de que un desarrollador pueda comentar por qué agregar esto a Mocha propiamente dicho dañaría a alguien (porque claramente ayudaría a mucha gente)?

@machineghost Me gusta el nuevo comportamiento por 2 razones:

1. Casi ninguna otra biblioteca saldrá después de que "haya hecho su trabajo". Por ejemplo, cerrar un servidor Node TCP no activará automáticamente una salida. De esa manera, es consistente con otras bibliotecas.
2. Si el nodo no sale, significa que todavía hay eventos esperando ser resueltos. Probablemente sea mejor intentar mejorar su código para que las cosas se limpien después de cada prueba. También podría sugerir que hay pérdidas de memoria.

Entonces, cuando me encuentro con esto, es un incentivo para intentar limpiar mi código para que no suceda.

Su perspectiva sobre esto podría ser 'no me importan las pérdidas de memoria' o 'no vale la pena arreglar esto en mi aplicación'. Si estás en esta categoría, lo más fácil es hacer un mocha.opts y agregar --exit .

Simplemente me parece que se trata de hacer más ruido, no de señal: en la gran mayoría de los casos, ninguna aplicación mejorará porque Mocha se colgó al final.

Si Mocha va a ser predeterminado, parece que debería terminar por defecto cuando las pruebas (y todas las llamadas after / afterEach ) hayan finalizado. No hacerlo solo para decirle a la gente "oye, tu entorno de prueba artificial es artificial" no beneficia a la mayoría (o incluso a una minoría decente) de los usuarios.

Si la gente realmente quiere depurar conexiones no cerradas, entonces parece que debería ser el caso para el que proporcione una opción. Pero el resto del tiempo, ¿realmente beneficia a los usuarios de la biblioteca confundir a todos los demás con (lo que equivale a decir) "estás en un entorno de prueba y una de mil millones de cosas posibles está abierta"?

Para decirlo de otra manera, si le vas a decir al 99% de las personas que se encuentran con esto "solo usa --exit ", entonces tal vez --exit no debería ser una opción especial que debas proporcionar ... tal vez el comportamiento predeterminado debería ser servir el 99% de los casos de usuario (mientras que, por supuesto, todavía les da a los usuarios la _opción_ de --tell-me-if-I-have-unclosed-stuff-in-my-testing-environment-and-that-is-actually-what-i-am-trying-to-find-out ).

Quiero decir, si hiciera esa opción, de manera realista, ¿con qué frecuencia cree que la gente la pasaría?

PD Acabo de encontrarme con esto: https://stackoverflow.com/questions/54999115/where-to-destroy-knex-connection. Si miras la segunda respuesta, este comportamiento en Mocha causó directamente que al menos un usuario (que no soy yo, y juro que no los conozco: encontré esto por suerte después de hacer mi última publicación) para agregar incorrecto código que no es de prueba (esta "función" les hizo pensar incorrectamente que era necesario llamar a knex.destroy() en su aplicación).

Versión resumida:

Persona agradable: probablemente no necesite llamar explícitamente a knex.destroy (); esto está implícito en la documentación en sí que dice (el énfasis es mío):

Persona agradable: citas documentos

Persona confusa: si no llamo a knex.destroy () mi script se bloqueará. Entonces, ¿qué significa que no necesitamos llamar explícitamente a knex.destroy ()

Persona agradable: Ah, solo mencionaste en otra parte que esto es para Mocha. Para usos regulares del servidor, no es necesario que elimine el grupo de conexiones; para Mocha, es posible que desee buscar en un gancho de eliminación global, consulte futurestud.io/tutorials/…

Pero para ser claros, este usuario tenía un entorno de trabajo, y debido a que Mocha (esencialmente) les dijo que su código en perfecto estado era incorrecto, perdieron quién sabe cuánto tiempo tratando de resolver el error que crearon al destruir sus conexiones. Y esa es solo esta persona desafortunada que lo hizo en público, y a quien vi por casualidad.

Entonces, supongo que lo que estoy tratando de transmitir es que no se trata solo de lo que es filosóficamente correcto, ni es solo que algo de ruido está ocultando señales útiles ... este comportamiento en realidad está causando daño y haciendo que los programadores pierdan el tiempo inclinándose en los molinos de viento.

Lo siento, confundí tu punto cansado con una pregunta honesta. Lamento haber respondido. Quizás los desarrolladores puedan bloquear este hilo.

"mocha --reporter mocha-allure-reporter ./tests/controllers --exit" funcionó para mí. De hecho, el --exit es una muy buena solución. Utilizo la versión 5.2.0 en mi proyecto.

¿Hay alguna manera de obtener el efecto equivalente de usar la bandera --exit cuando se usa mocha " programáticamente "?

No veo una opción documentada para exit / noexit, ni una forma general de pasar una cadena de bandera mientras uso la API NodeJS.

Siguiendo el patrón de otras opciones, probé:

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

pero no pudo obtener el efecto deseado.

La inspección rápida de https://github.com/mochajs/mocha/blob/master/lib/mocha.js parece mostrar que esta opción debe agregarse no solo a la documentación, sino también a la fuente.

Además de proporcionar una solución rápida (use --exit ), estoy de acuerdo en que dejaron el problema principal de encontrar las pruebas defectuosas al usuario. Yo mismo estoy luchando con eso ahora, pero cuando actualizo las versiones principales, me aseguro de leer las notas de la versión y no actualizar a ciegas

¿Cómo lo pasas exactamente? Este es mi script package.json

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } y no funciona

Además de proporcionar una solución rápida (use --exit ), estoy de acuerdo en que dejaron el problema principal de encontrar las pruebas defectuosas al usuario. Yo mismo estoy luchando con eso ahora, pero cuando actualizo las versiones principales, me aseguro de leer las notas de la versión y no actualizar a ciegas

¿Cómo lo pasas exactamente? Este es mi script package.json

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } y no funciona

Tuve el mismo problema y creo que no soy el único. Solo tenía que moverme, salir al final.
Esto no funcionó:
Portada de Estambul ./node_modules/mocha/bin/_mocha --exit - test / .test.jsEsto me funcionó:cubierta de Estambul ./node_modules/mocha/bin/_mocha - test / .test.js --exit

exit no hace nada cuando se ejecuta Mocha programáticamente, fwiw. el contenedor de CLI fuerza la salida del proceso, no Mocha-the-library.