Mocha: optar por no participar en globales

Incluso si simplemente tirara su basura por todo el espacio global cuando require('mocha') , sería mejor que el estado actual de las cosas.

No creo que sea una tontería, pero hay compensaciones con todo. Estaría feliz con algo como esto:

var Mocha = require('mocha');
var mocha = new Mocha(options);
mocha.describe('blah blah', function....

nadie lo usaría, pero al menos sería una forma más limpia de implementar lo que tenemos actualmente. Habría un _ton_ de texto estándar que todos tendrían que configurar cada vez, pero si pudiéramos reducirlos a API tipo CLI, estaría bien. Incluso si hubiera lib / cli.js que acaba de pasar en el ARGV, pero todavía dudo que alguien lo use, puede usarlo sin la CLI de manera razonablemente fácil, pero eso ilustra que nadie realmente quiere ir más allá de algunos casos extremos.

@visionmedia eso parece bastante bueno. La razón por la que sugerí require("mocha/bdd") o similar es que sería bastante fácil de implementar en términos de Mocha existente, pero sí, el tuyo probablemente sea mejor. (Podrías imaginar usarlo para, por ejemplo, ejecutar múltiples conjuntos de pruebas a la vez o algo así. Bueno, eso probablemente se rompería debido al uso de process.on ('uncaughtException'), pero ya ves lo que quiero decir).

Puedo intentar una solicitud de extracción para este día.

Este es un gran ejemplo en el que un poco de JavaScript futuro a través de la asignación de desestructuración es muy útil.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7#Destructuring_assignment_% 28Merge_into_own_page.2Fsection% 29

var [describe,it,beforeEach,afterEach] = new require("mocha")(options);

Solo desearía que hubiera soporte de armonía de nodos para esto.

¿Es la idea de esto poder hacer

node test/a-mocha-test.js

¿Y ha hecho esa prueba?

@glenjamin sí

Habiendo intentado hacer esto yo mismo en nodepec, el problema no era realmente hacer que las diversas funciones estuvieran disponibles, el problema era averiguar cómo / cuándo comenzar a ejecutar; todavía necesitaríamos un enfoque de definición / ejecución de dos pasos.

Las opciones que se me ocurrieron fueron:
1) haga que cada usuario agregue algo como mocha.exec () al final de cada archivo que desee ejecutar de forma aislada
2) Espere a que el núcleo agregue algo como process.on ('salir'), pero cuando el bucle de eventos aún esté disponible
3) suponga que cada archivo tiene solo un bloque de descripción de nivel superior y comience la ejecución cuando termine

(1) es probablemente el más bonito, que podría verse así:

var run = require('mocha/required');

describe('blah blah' , function() {
// ..
});

run();

Esto no parece agregar mucho más que hacer node ./node_modules/.bin/_mocha test/a-mocha-test.js cuando realmente necesita ejecutar sin el contenedor mocha .

Creo que esto ya no encaja con la forma en que se usa actualmente el moca. Como este hilo ha estado inactivo durante más de un año, lo cerraré por ahora.

Si alguien todavía está interesado en esto, no dude en comentar o proponer una solicitud de extracción y lo consideraremos :)

¿Podría reabrirse? Todavía estoy muy interesado en eso. No poder hacer solo node test.js pruebas de moca fue una de las principales razones por las que mis colegas y yo en Mapbox nos hemos estado alejando del moca por arneses como cinta y tap. Personalmente, preferiría seguir con el moka, pero encuentro que el argumento de la "capacidad de nodo" es algo convincente.

Editar: el argumento "capacidad de nodo" fue elaborado por @tmcw aquí .

Para mayor claridad, la falta de una interfaz require able no es el principal bloqueador aquí desde la perspectiva del usuario. Lo siguiente ya está documentado para funcionar:

var describe = require('mocha').describe;
var before = require('mocha').before;
var it = require('mocha').it;

Y se vuelve mejor con ES6:

import { describe, before, it } from 'mocha';

El problema es el hecho de que esto solo funciona cuando se ejecuta a través del binario mocha .

Oh, gracias por la aclaración. :) Si ya ofrecemos esta habilidad cuando se ejecuta usando el binario mocha, estoy de acuerdo en que sería bueno hacer lo mismo con node. Lo investigaremos. ¡Gracias!

Ahora que el nodo tiene un gancho antes de salir, esto parece bastante factible.

Tendría que ser algo como

var { describe, it } = require('mocha/auto')

Si. Como dijo TJ, el problema es que incluso si hiciéramos que todo sea "apto para nodos", es posible que se requieran demasiados estándares para ser útil.

Sin embargo...

@glenjamin gracias por el beforeExit . Creo que podríamos aprovechar esto. La gente probablemente todavía se quejaría de que es demasiado "magia" ...

Agregué una prueba de concepto a 3cdd4a04c48193cceac6af7db72af06d380014a9

de todos modos, necesitaría un poco de trabajo, pero creo que podemos generalizarlo fácilmente para todas las interfaces. aquí no hay soporte para Growl, mocha.opts o varias otras cosas relacionadas con process como códigos de salida. Deberíamos extraer algo de código de bin/_mocha y reutilizarlo aquí. Entonces también podríamos tener soporte de argumentos. Por ejemplo:

$ node test/my-test.js --reporter=dot

Si alguien tiene alguna sugerencia, déjame saber

Creo que extraer algunas de las cosas en bin/_mocha en algún tipo de CLI sería bastante sensato independientemente.

Sin embargo, todavía no estoy seguro de que sea una adición útil.

¿Existe mucha diferencia práctica entre cualquiera de los siguientes?

node test/test.js
./node_modules/.bin/mocha test/test.js
PATH=./node_modules/.bin:$PATH mocha test/test.js
npm test -- test/test.js

Tengo la sensación de que las personas que no usan moca porque no pueden ejecutar archivos de prueba a través de node son simplemente personas a las que no les gusta el moka y están buscando una excusa. Mocha no tiene por qué ser para todos: sonríe:

Igual que aquí. Estoy usando jspm y SystemJS y no puedo import Mocha en mis pruebas que se ejecutan en el navegador.

import { describe, before, it } from 'mocha';

No se puede usar cuando se usa en navegadores.

@glenjamin, es algo que tiene que suceder. Mocha debería tener una API programática central. Un buen efecto secundario de eso son las pruebas con capacidad para nodos. El entorno en el que se ejecuta consumirá la API programática, ya sea un navegador, CLI o algo completamente distinto. Mocha.app, ¿alguien? :)

Interesado en esta característica!

+1 para:
import { describe, before, it } from 'mocha';

Actualmente tenemos const {describe, it} = require('mocha') , pero no es necesario porque los globales ya existen.

Si nos preocupa la compatibilidad con el navegador, siempre podemos hacer const {describe, it} = window.mocha . Ya tenemos que hacer esto por chai .

bueno, const {describe, it} = window también, supongo.

esto es tan fundamental para la arquitectura de mocha que mocha exporta el objeto global cuando se incluye.

No creo que mocha deba definir ningún espacio global que no sea un solo espacio de nombres, y tal vez solo para navegadores.

el ejecutable mocha continuará usando globales; eso probablemente nunca cambiará.

lo que podemos (y debemos) buscar es la capacidad de ejecutar fácilmente pruebas de moca a través de node sin contaminar el espacio de nombres global. de eso se trata este tema.

desafortunadamente, esa es una bola de hilo del tamaño de Texas que nadie ha tenido el tiempo o la energía para desenredar, lo cual debería ser evidente a la edad de este problema ...

el ejecutable mocha continuará usando globales; eso probablemente nunca cambiará.

Si bien no sé nada sobre cómo está estructurado el moca, puedo afirmar que esta única elección de diseño es la fuente del problema.

probablemente así!

De hecho, eché un segundo vistazo al código, descubrí (más o menos) lo que había hecho mal la última vez que intenté piratear teniendo globales, pensé en lo que se necesitaría para que los archivos de prueba se pudieran ejecutar con node test/someFile.js , y creo que sé cómo hacer ambas cosas, con la salvedad de que hacerlo sin triplicar el número de casos extremos probablemente requiera romper algunos casos extremos existentes. Con más detalle, mis pensamientos sobre el diseño son:

• evitando globales
  
  
  
  • Incluso en un semver major no podemos romper la abrumadora mayoría del uso de Mocha que usa los globales. El equipo podría renunciar a sus trabajos diarios, no volver a dormir nunca, dedicar el resto de sus carreras a ello y, literalmente, no tener suficientes horas de trabajo para manejar la inimaginable avalancha de solicitudes de apoyo que ello implicaría. Por lo tanto: esto estará detrás de una bandera, para siempre .
  
  
  • Actualmente, las interfaces BDD y TDD tienen una carcasa especial: ambas se exportarán (y ninguna otra interfaz) como require("mocha").it et al. (Nota: la razón por la que esto no se rompe cuando se seleccionan otras interfaces puede ser que Mocha tiene un error en el que, en la mayoría de circunstancias, configurará la interfaz BDD incluso si se selecciona otra. # 2207) Quiero alejarme de esto.
  
  
  • Las interfaces personalizadas (de terceros) deberían poder funcionar con el esquema de exportación (siempre que utilicen el objeto de contexto emitido en lugar de codificar global ).
  
  
  • No podemos tener todas las interfaces posibles agregando sus funciones a Mocha (lo que exporta require("mocha") ).
  
  
  • Si alguna vez solucionamos el error en el que la interfaz BDD siempre está configurada, será complicado seguir exportando también las interfaces BDD y TDD en Mocha , se elige otra interfaz.
  
  
  • No debería configurar la interfaz de usuario de Mocha en TDD y usar la interfaz BDD o viceversa de todos modos, a menos que tal vez haga require("mocha/tddInterface").test o require("mocha/interface/bdd").it (no confundir con "mocha/lib/interfaces/<interface name>" donde las implementaciones en vivo).
  
  
  • Quizás podríamos mantener el comportamiento export-BDD-and-TDD-on-Mocha-if-possible para compatibilidad con versiones anteriores hasta un semver-major. No espero que mucha gente se queje cuando lo dejemos, dado que las personas que lo solicitaron y lo están usando saben más sobre lo que están haciendo que la mayoría y no están completamente satisfechos con él de todos modos (ya que el globales todavía están allí).
  
  
• capacidad de nodo, es decir, poder ejecutar node test/someFile.js lugar de mocha test/someFile.js
  
  
  
  • Si bien es menos omnipresente que los globales, no creo que podamos permitirnos el lujo de romper a las personas que usan var Mocha = require("mocha"); var mocha = new Mocha() etc. (es decir, la "interfaz programática"). Tendríamos que detectar eso y evitar ejecutar Mocha "de la manera capaz de nodos" o de lo contrario (más fácil para nosotros, pero requiere la suscripción de los usuarios) requerir que se acceda a la capacidad de nodos a través de una importación diferente, por ejemplo require("mocha/nodeable").it ( .describe etc.). Una importación especial en lugar de llevarla a cuestas en require("mocha") sería más fácil de implementar de manera segura y encajaría con mi deseo (descrito y justificado en la sección de evitar globales) de alejarme de la exportación de interfaces en el objeto Mocha exportado por require("mocha") .
  
  
  • Para poder node test/someFile.js , no es suficiente que someFile.js pueda importar la interfaz de Mocha: se debe crear una instancia de Mocha y, una vez que se hayan configurado todas las pruebas, Mocha debe ejecutarse. En otras palabras, require("mocha/nodeable") debe crear una instancia de Mocha además de exportar la interfaz, y luego ... después de que se ejecuta el archivo de prueba, debe ejecutar Mocha.
  
  
  • Una forma de hacer esto sería ejecutar Mocha en process.on("beforeExit" , siempre que el archivo de prueba no inicie ninguna acción asincrónica.
  
  
  • Otra forma de hacer esto sería ejecutar Mocha en process.nextTick o setImmediate o setTimeout(..., 0 /* or some small number */) .
  
  
  • Las pruebas que configuran sus cosas con --delay y se ejecutan de forma asincrónica con run() serían un problema. No por saber cuándo ejecutar (eso es más fácil, hay run() ) y ni siquiera por saber si --delay (ver más abajo, o proporcionar require("mocha/nodeable/delayed") ), sino porque Se supone que run() solo se debe llamar en un archivo de prueba como está diseñado actualmente. Podría decirse que ya es difícil trabajar con ese diseño y tendríamos que arreglarlo para que se invoque run() en cada archivo de prueba de todos modos, en cuyo caso usarlo con pruebas "nobles" sería fácil después arreglando lo. De lo contrario ... no estoy seguro de qué hacer.
  
  
  • Si queremos permitir la llamada a estos archivos de prueba a través de mocha lugar de node (es decir, usar esto no fuerza el uso de node ), entonces lo que sea require d tiene que detectar cuando la CLI está en uso y no crear una instancia de Mocha en ese momento. Esto sería más fácil que detectar cuando la API programática está en uso: la CLI puede establecer algún estado global que estos módulos verificarían, o estos módulos pueden verificar si la CLI es el archivo que ejecutó Node.
  
  
  • Necesitaríamos hacer que las piezas de la CLI sean más modulares si quisiéramos admitir el paso de indicadores de Mocha cuando se ejecuta a través de Node, o usar mocha.opts , o cualquier cosa que permita que los archivos de prueba con capacidad para nodos usen un comportamiento diferente al predeterminado de Mocha comportamiento.
  
  
• Combinando las limitaciones de estas dos ideas, propongo (y creo que puedo implementar) :
  
  
  
  • evitando globales
  
  
  • En lugar de pasar interfaces el objeto global para poner sus funciones, les pasará un "objeto de interfaz seleccionado". (EDITADO PARA AÑADIR: esto debe hacerse tanto en lib/mocha.js como en browser-entry.js . Hasta donde yo sé, todas las partes de la propuesta relacionadas con el mundo son factibles tanto en Node como en el navegador. )
  
  
  • Luego, copiará todo el contenido del objeto de interfaz seleccionado en global .
  
  
  • Una opción localInterface ( --local-interface en la CLI) evitará que Mocha copie desde el objeto de interfaz seleccionado a global .
  
  
  • DEBATABLE: Inicialmente, para compatibilidad con versiones anteriores con require("mocha").it Mocha copiará las funciones TDD / BDD del objeto de interfaz seleccionado en Mocha también, pero esto quedará obsoleto / eliminado más adelante.
    
    
    
    
    
    • (NOTA: si evitamos que se configure BDD cuando no está seleccionado, es posible que tengamos que hacer un manejo aún más especial aquí para configurar el BDD en un objeto de interfaz seleccionado ficticio desde el cual se pueden copiar, un buen caso para eliminar el comportamiento en conjunto, se vuelve más complejo cuanto más otras cosas arreglamos / mejoramos mientras seguimos tratando de respaldar esto).
    
    
    
  
  
  • require("mocha/interface") exportará el objeto de interfaz seleccionado.
  
  
  • require("mocha/interface/<specific interface>") llamará a la interfaz especificada con un nuevo objeto de interfaz seleccionado que posteriormente exportará.
  
  
  • EDITADO PARA AÑADIR: require("mocha/interface") también será una propiedad en el objeto mocha en el navegador, mocha.interface , para admitir el uso del navegador sin un sistema de módulos.
  
  
  • habilidad de nodo
  
  
  • require("mocha/nodeable/<specific interface>") creará una instancia de Mocha, configurará Mocha para que se ejecute después del archivo de prueba (presumiblemente usando setTimeout menos que se use delay , ver más arriba sobre delay ) y exportar un objeto de interfaz seleccionado para esa interfaz como require("mocha/interface/<specific interface>")
  
  
  • Si se admiten las opciones de CLI o mocha.opts , require("mocha/nodeable") crearía una instancia de Mocha, configuraría Mocha para que se ejecute después del archivo de prueba (ver más arriba) y realice los mismos pasos de configuración de interfaz que la CLI, exportando el objeto de interfaz seleccionado como require("mocha/interface") .
  
  
  • Si queremos que los archivos de prueba con capacidad para nodos también sean mocha -able, entonces mocha/nodeable & mocha/nodeable/<specific interface> no es necesario, podemos aprovechar la capacidad de nodos en mocha/interface & mocha/interface/<specific interface> .
  
  

Pensamientos

En realidad, pensándolo bien, hago una moción para cerrar este boleto, por el siguiente motivo en contra de usar node <test file> en lugar de mocha <test file> :

• No conozco las ventajas que ofrece.
  
  
  
  • Una posible idea es que solo ejecuta un único archivo de prueba, independientemente de los globs que haya en mocha.opts . Solución simple: ponga globs en el script test en package.json lugar: npm test los ejecutará todos y mocha ( node_modules/.bin/mocha , npx mocha ) ejecutará solo los archivos de prueba especificados. (Los archivos o elementos globales que deben ejecutarse para cualquier ejecución de prueba, independientemente de cuántos archivos de prueba se ejecuten, deben ir en mocha.opts ).
  
  
  • Otra posible idea es que permite omitir mocha.opts completo. Esto debería ser posible ahora usando mocha --opts /dev/null (o en Windows mocha --opts nul ). Si por alguna razón no es así, sería más sencillo implementar un indicador CLI para omitir el procesamiento de mocha.opts .
  
  
• Se puede implementar fuera de Mocha; en lugar de "mocha/nodeable" , simplemente coloque el mismo código usando la API programática de Mocha en un paquete hipotético "nodeable-mocha" .
  
  
  
  • No estoy diciendo que sea fácil de implementar en primer lugar, estoy diciendo que no tengo conocimiento de ninguna forma en que pueda ser más difícil de implementar debido a que no estoy en Mocha.
  
  

Si descubrimos alguna ventaja significativa que sea más fácil de lograr en el núcleo que fuera de él, siempre podemos reabrir.

Sin embargo, también hago una moción para reabrir el boleto de evitación global, porque:

• Si bien es poco probable que las ventajas sean relevantes (¿cuántas otras bibliotecas están usando globales llamadas describe , it etc.?), Son posibles en principio (la respuesta a esa pregunta podría ser mayor que 0, aunque pocos) - no descargar cosas en el espacio de nombres global es, teóricamente, lo correcto.
  
  
  
  • Además, mi plan extendería el mismo comportamiento a las interfaces de terceros que están escritas correctamente para usar el objeto de "contexto" emitido (para el cual Mocha actualmente siempre usa el objeto global) en lugar de codificar el objeto global; Si bien es poco probable que nuestras propias interfaces interfieran con otras bibliotecas, no podemos ofrecer ninguna garantía sobre otras interfaces, por lo que también les facilitaríamos hacer lo correcto.
  
  
• Mi plan limpiaría muchos casos extremos relacionados en el comportamiento actual (por ejemplo, extendiéndolo a interfaces de terceros, pero también consistencia en Mocha en lugar de incluir las interfaces BDD y TDD en una carcasa especial).
• La única manera fácil de implementarlo fuera de Mocha es usar la API programática de Mocha y parchearla , y esto dejaría algunas de las inconsistencias y casos extremos antes mencionados.

por lo que está sugiriendo que Mocha proporciona una forma de ejecutar pruebas con mocha pero detrás de una bandera que no contaminará global ?

parte de lo que hace mocha mocha y parte de su éxito es que no requiere un texto estándar para importar cosas. A pesar del dogma sobre la contaminación del espacio de nombres global, existen razones completamente válidas para hacerlo por motivos de ergonomía para desarrolladores.

¿Entonces estás sugiriendo que Mocha proporciona una forma de ejecutar pruebas con mocha pero detrás de una bandera que no contaminará globalmente?

Sip.

parte de lo que hace mocha mocha y parte de su éxito es que no requiere un texto estándar para importar cosas. A pesar del dogma sobre la contaminación del espacio de nombres global, existen razones completamente válidas para hacerlo por motivos de ergonomía para desarrolladores.

No estoy diciendo que no esté de acuerdo en general, pero como una función de suscripción , puedo ver dónde algunos desarrolladores pueden querer importaciones en lugar de globales (tal vez quieran que su módulo nombre una variable local context sin hacer referencia accidental al global si olvidan var , tal vez les gustaría usar una interfaz de terceros donde ese tipo de colisión es aún más probable), y ahora que he descubierto cómo hacerlo bien, es También es más fácil de hacer en Mocha que como un complemento de algún tipo (de hecho, si no me atrapan en otra cosa, probablemente prepararé un borrador en una rama esta semana para demostrarlo).

(Además, ya estamos Mocha para que pueda require("mocha").it , pero la versión ya estamos mantener, francamente, es extraño, inconsistente , propenso a errores y ni siquiera evita contaminar el espacio de nombres global. Si vamos a mantener ese tipo de característica, es mejor que la corrijamos en lugar de mantener una versión dudosa).

Esto es IMO en contraste con poder node <test file> para las pruebas de Mocha, que hasta donde yo sé no tiene ninguna ventaja y sería igualmente difícil de implementar dentro o fuera de Mocha.

@stevenvachon
¿Cómo es que const {describe, it} = require('mocha') no me funciona? Solo tengo indefinidos ...

$ node -v
v8.4.0

@zapphyre , aún necesita ejecutar el conjunto de pruebas a través del programa mocha , no a través de node .

No puede ejecutar varios archivos fuente con node , por lo que está atascado con mocha . No conozco un corredor / marco de prueba que no tenga su propio ejecutable.

Se actualizó el título del problema para que sea más específico.

Otra razón para esto: me gustaría ejecutar pruebas usando un tiempo de ejecución JS diferente, por ejemplo, low.js (porque es una de nuestras plataformas, otras son node.js, navegador y React Native). Puedo hacer eso cuando tengo un archivo JS que importa moca y ejecuta las pruebas, no puedo hacer eso cuando tengo que llamar a mocha para ejecutar las pruebas.

Quiero decir, ya lo haces para el navegador. En esa plataforma tengo código JS que importa "mocha" y luego ejecuta las pruebas desde un objeto mocha global usando mocha.run() .

En el navegador yo

• Cargue mocha y obtenga un objeto mocha global
• Ejecutar mocha.setup({ui: 'bdd'});
• Cargue todos los archivos de prueba usando SystemJS
• Entonces corro

      mocha.checkLeaks();
      mocha.globals([]);
      mocha.run();

Y eso es. Cuando intento lo mismo en node.js, usando una declaración require en lugar de SystemJS para cargar un archivo de prueba, obtengo (usando mocha 5.2.0)

> mocha.run();
TypeError: Cannot read property 'search' of undefined
    at Mocha.mocha.run (/home/mha/one/node_modules/mocha/mocha.js:149:54)

EDITAR: Probé https://github.com/mochajs/mocha/wiki/Using-Mocha-programmatic y mocha.addFile lugar de solo cargarlo, el mismo resultado.

¿Existe actualmente alguna forma de importar describe / it?

Hay una nueva página Wiki (a partir de ahora 20 horas) https://github.com/mochajs/mocha/wiki/Using-mocha-programmatic, pero es para ejecutar las pruebas.

Otra razón para esto: me gustaría ejecutar pruebas usando un tiempo de ejecución JS diferente, por ejemplo, low.js (porque es una de nuestras plataformas, otras son node.js, navegador y React Native). Puedo hacer eso cuando tengo un archivo JS que importa moca y ejecuta las pruebas, no puedo hacer eso cuando tengo que llamar a mocha para ejecutar las pruebas.

Si el tiempo de ejecución alternativo tiene un ejecutable similar a un nodo (¿lo que creo que low.js tiene?) Entonces puedes hacer alternative-executable ./node_modules/.bin/_mocha , y eso debería funcionar

No conozco un corredor / marco de prueba que no tenga su propio ejecutable.

https://github.com/tapjs/node-tap/#tutti -i-gusti-sono-gusti

Ahora que https://github.com/mochajs/mocha/issues/3006 está resuelto, sería bueno tener las exportaciones con el mismo nombre en el navegador.

Actualmente, lo siguiente está funcionando:

<script type="module">
  import './node_modules/mocha/mocha.js'
  console.log(mocha)
</script>

Pero lo siguiente no es:

<script type="module">
  import { mocha } from './node_modules/mocha/mocha.js'
  console.log(mocha)
</script>

(según lo solicitado por https://github.com/mochajs/mocha/issues/956#issuecomment-167453800)

Esto podría resultar más fácil cuando fusionamos nuestra rama con roll-up y configuramos los transpilers. Parece factible tener un paquete esm y un paquete heredado que consume las rutas del código esm y agrega las fugas globales. Tendríamos que tener mucho cuidado para hacer cambios solo en las rutas de código y paquetes recién agregados para no romper o codificar en los navegadores y

Con variables globales y tipificaciones, esto solo hace que el legado de mocha sea algo.

Por cierto, acaba de crear @types/mocha sin globales: https://github.com/whitecolor/mocha-types

Espero que (globales) se eliminen oficialmente pronto.