Es mejor que cree dos directorios paralelos, uno para pruebas y el otro
para archivos de datos. Eso fue lo que hice.
Am 04.03.2015 15:52 schrieb "Kyle P Davis" [email protected] :

Me gustaría tener la capacidad de proporcionar un patrón de exclusión para poder
solo archivos de prueba que coincidan con mi patrón de archivo de prueba. Esto permitiría datos
que coexistan con archivos de prueba siempre que sigan un
patrón.

Creo que esto sería simplemente proporcionar una opción que establece la opción ignorar
en glob.

Pensamientos Puedo hacer un PR muy rápido si quieres.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/mochajs/mocha/issues/1577.

Podría (y lo hice en el pasado) pero preferiría no tener que hacer eso más ahora que me he dado cuenta de que glob ignore está ahí.

Debería ser bastante fácil agregar un argumento de línea de comando para configurar la opción de ignorar glob. Solo quería tener pensamientos y discutir un poco primero.

¿Alguna objeción a que cree un PR para esto?

Yo solo necesitaba esto también y me sorprendió ver que Mocha aún no lo tenía. Creo que sería una gran adición. Tenemos una "aplicación de prueba" dentro de nuestra carpeta de prueba que usamos específicamente para realizar pruebas. No queremos que mocha intente ejecutar pruebas dentro de esa carpeta. Sería bueno poder agregar una exclusión a nuestro archivo mocha.opts para excluir esa ruta específica en lugar de tener que incluir explícitamente todas las demás subcarpetas de prueba que tenemos.

Si bien podríamos sacar la aplicación de prueba, realmente no cabe en ningún otro lugar del repositorio y tiene una ruta relativa a ciertos archivos en la carpeta de prueba.

Creo que esto sería una buena adición. Ciertamente no es crítico, pero útil.

@KylePDavis @toddbluhm

Si necesitara esto, creo que probablemente solo

$ mocha $(find test/ ! -path '*testApp*')

Así que no estoy realmente emocionado con la idea. Estoy un poco indeciso acerca de la existencia de la bandera recursive incluso, ya que se puede lograr lo mismo con un comando de shell, Makefile , Gruntfile.js , gulpfile.js , etc., etc.

Creo que @boneskull tiene un buen punto: esto ya se puede lograr de varias maneras. Y eso sin incluir el hecho de que puede estructurar sus directorios para evitar esto por completo. Por ejemplo, dada esta estructura:

$ tree .
.
└── spec
    ├── fixtures
    ├── integration
    └── unit

4 directories, 0 files

Simplemente actualice su package.json para que pueda simplemente ejecutar npm test

  "scripts": {
    "test": "mocha spec/unit spec/integration"
  }

O con una estructura como la siguiente:

$ tree .
.
└── src
    └── models
        ├── user.js
        └── userSpec.js

2 directories, 2 files

Puede ejecutar especificaciones de manera similar al ejemplo de @boneskull (esto solo ejecutará archivos que contengan Spec )

  "scripts": {
    "test": "mocha $(find src -name '*Spec.js')"
  }

Editar: fijo :)

@danielstjules Creo que en realidad llegará a cualquier directorio con Spec en el nombre. Quizás quieras -name '*.spec.js'

¡Sí, tienes razón! Pedo cerebral. Gracias por señalar eso.

Comando fijo para el ejemplo:

  "scripts": {
    "test": "mocha $(find src -name '*Spec.js')"
  }

Creo que todavía hay un caso de uso válido para esta función: tiendo a agrupar mis archivos por función, por lo que cada archivo de prueba está junto a los archivos que contienen la lógica que están probando. Nombrar los archivos de prueba consistentemente trabaja con el file discusión o grep opción, pero me gustaría hacer caso omiso de manera explícita cosas como node_modules .

Para cualquiera que busque, gulp-mocha puede lograr esto, simplemente odio incluir gulp donde no tengo que hacerlo.

Me gustaría tomarme un momento y hacer +1 en esta idea. A diferencia de los proyectos típicos de JavaScript, me gusta seguir la forma en que GO hace las pruebas unitarias e incluyo un archivo de especificaciones junto a cada archivo que se prueba. Por ejemplo, un directorio en uno de mis proyectos puede tener el siguiente aspecto:

main.js
main.spec.js
utilities.js
utilities.spec.js

Creo que este tipo de organización hace que sea mucho más fácil encontrar pruebas que buscar en un solo directorio de archivos de prueba; siempre espera que la prueba se ubique junto al archivo que prueba y mi script de compilación scripts todos los archivos .spec.js en la versión implementada.

Debido a mi diseño no estándar, lo que me gustaría poder hacer es ejecutar todas las pruebas unitarias con todas mis carpetas, excluyendo el directorio node_modules.

No tengo un cuadro de Windows cerca de mí en este momento, pero no estoy seguro de si esa sintaxis de búsqueda funcionaría en Windows o no; una opción de exclusión sería mucho más intuitiva de todos modos en mi opinión. Además, casi todos los marcos de prueba unitarios incluyen una forma de ignorar archivos de todos modos, por lo que la paridad estaría bien.

Hola, todas mis pruebas admiten el formato *.test.js . Todos están en el directorio tests . Actualmente tengo un par de pruebas que quiero excluir y aún conservo la ruta predeterminada para mocha, que es ./test/**/*.js . ¿Cómo puedo hacer eso?

La creación de dos directorios separados no funcionará aquí, y debe aceptar que mover las pruebas entre directorios crearía mucho ruido en VCS.

@calebthebrewer Afortunadamente estoy usando gulp en el proyecto;) ¡gracias por la pista!

+1 @calebthebrewer

Angular 2.0 y Polymer me tienen en modo componente, así que estoy de acuerdo con @KrisSiegel. Mantener todo su código en paquetes mantiene una jerarquía de archivos limpia, modular y fácil de mantener.

¿Existe algún problema previsible para cargar las pruebas usando la biblioteca de promesas q de una manera como esta:

import q from 'q';

import authRouterTest from '../app/routes/_authentication.router.e2e.js';

import productRouterTest from '../app/routes/_product.router.e2e.js';

import productModelTest from '../app/models/product.model.spec.js';

// Dynamically constructed sequence of functions
let funcs = [ productModelTest(), authRouterTest(), productRouterTest() ];

// This function takes an array of promise-producing functions and
// runs them sequentially.
let execTests = () => {

    let result = q();

    funcs.forEach((f) => {

        result = result.then(f);
    });

    return result;
};

// Execute tests
execTests();

De esta manera, puede importar sus archivos desde cualquier lugar y solo tener un archivo de prueba en test/ .

Puede resolver la promesa dentro del último bloque de prueba y terminar cada prueba así

import q from 'q'

export default () => {

    let Q = q.defer();

    describe('something', () => {

        it('should', (done) => {

            ...
        });
    });

    describe('something', () => {

        it('should', (done) => {

            ...
        });

        it('should', (done) => {

            ...

            Q.resolve('test complete');
        });
    });

    return Q.promise;
};

Parece funcionar bastante bien, a menos que haya algo que no esté considerando.

Todavía deberíamos ignorar el glob. El uso de comandos bash no es una solución multiplataforma.

+1

Realmente me gustaría excluir node_modules . Exclusion parece un compañero muy útil para recursive .

@godspeedelbow ¿ node_modules esté en un directorio de prueba.

FWIW, realmente podría usar esto también. Tengo un par de proyectos donde las pruebas escalan mucho más que la biblioteca en sí, y esto me permitiría organizarlas mejor (los accesorios pertenecen a un directorio de prueba en mi humilde opinión).

Ignorar node_modules vuelve importante cuando estás haciendo algo inesperado (como yo, donde guardo los archivos de especificaciones junto al archivo que prueba en lugar de guardarlos en una sola carpeta, lejos del código que prueba) o si lo deseas para ejecutar pruebas unitarias contra un proyecto principal y algunos de sus proyectos incluidos (tal vez sean bibliotecas internas, no en el repositorio npm, que le gustaría probar) pero no desea ejecutar las pruebas unitarias dentro de sus propias dependencias .

Este problema ha existido durante casi un año completo, por lo que no tengo muchas esperanzas de que se implemente. En mi opinión, es importante implementarlo porque las soluciones alternativas requieren comandos de terminal específicos de la plataforma o usted especifica explícitamente patrones para cada directorio que desea probar (por lo que es necesario agregar directorios adicionales al script de prueba). Lo bifurcaría y lo haría yo mismo, pero usar el método hacky de especificar cada directorio y un patrón es más fácil que encontrar el tiempo para implementarlo en mocha.

@KrisSiegel Siempre puedes hacer src/**/*.js y src/**/*.spec.js . Veo eso con más frecuencia en los proyectos Go y Rust que en la raíz del proyecto. De hecho, este último es relativamente poco común.

Aunque creo que solo están esperando a que alguien se tome el tiempo para hacerlo ellos mismos. No parece un parche difícil de crear (a menos que esa lógica sea un lío de máquina de estado de código espagueti).

No estoy tan motivado para hacer esto personalmente porque en realidad estoy trabajando en un marco de prueba propio, destinado a ser una alternativa completa a Mocha, Jasmine, Tape, etc., aunque más simple y más poderoso en su esencia. Sin embargo, todavía es demasiado trabajo en progreso incluso para proyectos de juguetes ATM.

Estoy usando Mocha para arrancar eficazmente el marco. Usé Chai inicialmente para las afirmaciones hasta que las estabilicé (ahora están prácticamente bloqueadas por API, ya que estoy usando las afirmaciones del marco para probarse a sí mismo).

Sí, esa es una solución. Simplemente no veo muchos proyectos de JavaScript estructurados de esa manera, aunque también se podría decir lo mismo sobre el emparejamiento de la especificación y el archivo fuente. Básicamente utilizo ese patrón, aunque cuando entro en proyectos que ya son bastante grandes con sus propios sistemas de compilación personalizados, no siempre es fácil cambiarlo.

Excluir es un patrón bastante básico que tienen muchas utilidades. Creo que mocha lo necesita :). Aunque supongo que mi impresión, dado que este problema se cerró en función de soluciones alternativas específicas de la plataforma, no era lo deseado en lugar de esperar un parche. Si esto es algo que la gente del moca realmente querría, entonces si no se hace en unas pocas semanas, ciertamente podría poner en marcha un parche.

@KrisSiegel Estoy bastante seguro de que si alguien realmente creara un parche, probablemente se fusionaría, siempre y cuando no implique una sintaxis especial, poco intuitiva o un indicador adicional. FWIW, todavía no ha habido un PR para _ esto_, y la razón por la que se cerró este problema fue bastante débil si se considera que depende de la find solo para ejecutar algunas pruebas.

Puede que esté cerrado, pero una situación similar ya le está sucediendo a Node con los trabajadores web , aunque la implementación de Node se desviará ligeramente ( problema cerrado , PR en progreso ).

+1 por lo que vale. Un proyecto que he construido no requiere una carpeta app o src , sino que tiene una cantidad variable de carpetas nombradas con diferentes implementaciones de interfaz. También me gustaría mantener mis pruebas agrupadas para cada interfaz y no verme obligado a usar una sola carpeta para las pruebas.

Ser capaz de especificar archivos para ignorar con .mochaignore u otra opción sería ideal, ya que de esa manera podría ejecutarlo con un **/*.spec.js glob y no preocuparme de que pueda incluir pruebas de node_modules carpeta.

Casi todas las demás herramientas de compilación permiten esto, tenemos .npmignore , .gitignore , .jshintignore , y jscs proporciona una opción para configurarlo a través de .jscsrc . Sería útil que Mocha también lo admitiera, ya que cada vez más personas se están moviendo hacia la organización de archivos y carpetas de componentes / características, alejándose del enfoque del cajón de calcetines.

@isiahmeadows como otros mencionaron, estoy atascado con una estructura de carpetas que no puedo cambiar fácilmente, por lo tanto services/ , routes/ , etc.están en la raíz del proyecto al igual que node_modules es. Me inspiré para poner archivos de prueba junto a los archivos que prueban. Esto funciona muy bien, pero necesito una tercera herramienta (ya sea una línea de comando, o gulp, o algo más) para excluir node_modules para que solo se prueben mis propias pruebas.

Me encantaría implementarlo yo mismo en moca, si supiera por dónde empezar :)

@godspeedelbow @adambuczynski Una solución temporal :)

  "scripts": {
    "test": "mocha $(find . -name '*.spec.js' ! -ipath '*node_modules*')"
  }

Hola @danielstjules ¡gracias! Lo intenté, pero por alguna razón find . -name '*.spec.js' ! -ipath '*node_modules*' solo encuentra un archivo de prueba.

¿Actualizó '*.spec.js' para ajustarse al patrón que siguen sus pruebas? Por ejemplo, para hacer coincidir los archivos _todos_js, usaría:

  "scripts": {
    "test": "mocha $(find . -name '*.js' ! -ipath '*node_modules*')"
  }

@danielstjules aplaude , pero atrevo a instalarla .

Mientras tanto, he recurrido a mover el código de la aplicación y las pruebas a una subcarpeta app para poder apuntar a esa carpeta para las pruebas y no preocuparme por node_modules u otras carpetas.

@danielstjules sí, todos los archivos de prueba están en formato *.spec.js . Por alguna razón no funcionó antes, pero ahora lo hace sin problemas. Gracias por esta solución de * NIX.

Quiero ver esto hecho para una próxima especialización; el apoyo específico a .mochaignore parece razonable

@boneskull Gracias, sería genial.

Para la próxima versión principal, ¿también consideraría la implementación de un .mocharc más "estándar" para pasar las opciones, que se puede poner en la raíz del proyecto, en lugar de tener que usar un mocha.opts en la carpeta test ?

Eso haría que la configuración de Mocha fuera mucho más fácil y de acuerdo con la forma en que se hace con otras herramientas que existen. Además, no nos obligaría a tener una carpeta test solo para mocha.opts . (Colocamos todas nuestras pruebas junto con los módulos que prueban).

@adambuczynski absolutamente. No soy fan de mocha.opts

@adambuczynski gran comentario. Estoy de acuerdo, también me gustaría tener un archivo de opción .mocharc estándar, ya no uso un directorio de prueba, ya que es muy bueno mantener las pruebas junto al código.

+1, creo que la exclusión es realmente necesaria.

@adambuczynski @boneskull La documentación indica que puede usar --opts para especificar cualquier ruta a su archivo de opciones, aunque no da ningún ejemplo. Estoy usando esto en mi proyecto actual y puedo confirmar que funciona como mocha --opts .mocharc

Gracias @GRUBES. Al final, seguí usando la carpeta test porque también coloco mis ayudantes de configuración de prueba allí, pero es bueno saber que es posible.

Glob tiene una opción de ignorar, por lo que no debería ser un gran problema agregar una opción de exclusión y reenviarla a glob ignore.

ignorar Agrega un patrón o una matriz de patrones globales para excluir coincidencias. Nota: los patrones de ignorar siempre están en modo punto: verdadero , independientemente de cualquier otra configuración.

No estoy seguro de por qué esto lleva más de un año. :-)

@ inf3rno Por cierto, esto probablemente se habría resuelto mucho antes si alguien se hubiera sentado y hubiera escrito el parche.

@isiahmeadows Ye, pero ese no seré yo. :RE

Entonces, ¿esto todavía necesita un PR? Me complacería agregar esto, ya que preferiría usar la colocación de archivos de prueba en lugar de los directorios múltiples para test y test-integration

2036, que es básicamente para el mismo tipo general de cosas, solo un archivo en lugar de una opción de línea de comando, tiene un PR # 2173

Tal vez sea bueno agregar una opción como --exclude .

O admite algo como mocha test/*.js !test/_*.js

Calculado Glob: mocha "./{,!(node_modules)/**/}*.test.js" para obtener todos los archivos * .test.js excepto en node_modules, y mocha "./test/**/!(notThisOne).js" para obtener todo en la carpeta y subcarpetas de prueba excepto notThisOne.js

Ver también:
https://github.com/isaacs/node-glob#glob -primer
https://github.com/isaacs/node-glob/issues/62

@ScottFreeCode

Cuando corro en la terminal obtengo

mocha "./{,!(node_modules)/**/}*.test.js"
-bash: !: event not found

¿Debería escapar este personaje?

@mdumouchel Utilice comillas simples. De lo contrario, sí lo hace.

@isiahmeadows

Sigo recibiendo error

node_modules/mocha/lib/utils.js:630
        throw new Error("cannot resolve path (or pattern) '" + path + "'");
              ^
Error: cannot resolve path (or pattern) './{,!(node_modules)/**/}*.test.js'

Terminé usando el comando de búsqueda

mocha $(find . -type d -name node_modules -prune -o -name '*.test.js')

@mdumouchel Si está utilizando la versión 2.x (es decir, lo que está en npm), de todos modos no funcionará. El soporte comenzará en 3.x, IIRC.

Eso es extraño, pensé que lo intenté en Bash y pude usar comillas dobles. ¿Alguien conoce una sintaxis / escape que funcione tanto en Windows como en Bash?

Además, estoy bastante seguro de que el error "no se puede resolver la ruta" significa que la ruta no coincide con ningún archivo de su proyecto; la ruta que proporcioné funcionó en la versión actual cuando tenía archivos de prueba con nombres que terminan en ".test.js" junto con los archivos fuente correspondientes, a menos que me equivoque al copiarlo de mi prueba al comentario del problema ...

Ver # 2173

Eslint hace un gran trabajo ignorando archivos con --ignore-path (y .eslintignore ).
Ver: http://eslint.org/docs/user-guide/command-line-interface#ignoring -files

Algo similar para mocha sería genial: two_hearts:

Mi solución:

eslint "test/!(fixtures)/**/*.js" "test/*.js"

Mi estructura de archivos

.
└── src
└── test
    └── fixtures
        └── data.js
    ├── foo.js
    └── bar.js

Problema: Mocha me da un Error: cannot resolve path (or pattern) si alguna de las 2 rutas no coincide con algo ...: decepcionado_aliviado:

OK, entonces cedí. Esto simplemente no es fácil de usar.

Esto es lo que creo que deberíamos hacer:

1. Soporte --exclude <glob-or-path>
2. Admite _múltiples_ instancias de --exclude
3. Combine todas las opciones --exclude con todos los argumentos que no sean de opción en una sola lista (básicamente lo que hace globby )
4. Carga esos archivos

Actualmente admitimos _n_ argumentos que no son de opción, que pueden ser todos globales, pero esto es solo _aditivo_; esto no funciona como cabría esperar:

$ mocha 'src/**/*.spec.js' '!src/forbidden/**/*.spec.js'

Entonces, lo anterior debería funcionar, y --exclude es realmente solo azúcar por ! .

Además, la compatibilidad con .mochaignore (# 2036) suena bien, pero es un tema aparte. Debería haber un módulo 3p que podamos incorporar para tener .gitignore comportamiento similar a

... y si no está claro, no use globs sin comillas en la línea de comando; ver # 2355

Sorprendentemente, todavía no hay una opción como --ignore-path , además de poner todas las pruebas en una carpeta tests , no hay ninguna razón por la que no podamos poner pruebas junto con los módulos.

+1
ignorar archivos o directorios por patrón es una característica muy útil

@isiahmeadows

Siempre puedes hacer src / / .js y src / /.spec.js

No, no podría: la coincidencia de patrones **/* está rota y no funciona de forma recursiva.

EDITAR: @ScottFreeCode tiene la respuesta a continuación

la coincidencia de patrones **/* está rota y no funciona de forma recursiva.

¿Están citados sus caminos?

+1

Como se describe en https://github.com/zinserjan/mocha-webpack/issues/124 :

Dentro de src/ hay un archivo llamado server.ts que activa un servidor expreso y se ejecuta en segundo plano. El servidor normalmente está activo cuando se ejecuta la cobertura, por lo que el puerto ya está en uso.

Por lo tanto, no queremos que se excluya este y solo este archivo.

http://remarkablemark.org/blog/2017/02/07/mocha-glob-pattern/

Expresando mi opinión de que el moka necesita ser ignorado porque incluso después de todo este tiempo, los mantenedores todavía necesitan ser convencidos.

Mocha es canon. ¿Por qué no subir el listón del conjunto de características multiplataforma del marco de prueba que todos los demás marcos de prueba aspiran a ser? Deberíamos dejar de aspirar a dejar todo en manos de Bash. Ya es 2017.

También señalaré que la gente de Windows no tiene nada equivalente al !(glob) Bash (que en realidad es un bashismo, ni siquiera el estándar POSIX).

No debería haber ninguna dependencia de Bash en el globbing de Mocha tal como está, ya que se procesa a través del módulo Glob JS. (Nota: es posible que sea necesario citar las rutas para evitar los glob de procesamiento de shell de manera diferente a como lo haría Mocha, por ejemplo, ** sin la extensión globstar o lo que sea que lo haga especial).

@ScottFreeCode ¿Usa extglob: true cuando usa glob? Si ese es el caso, entonces esto se puede cerrar con esa sintaxis como una solución alternativa (ya que glob / minimatch lo admite con esa opción habilitada).

Parece que estamos pasando por el camino de glob . Estoy bastante seguro de que obtuve la negación funcionando a través de un patrón global en algún momento, pero ¿puede haber sido una versión anterior del módulo? En cualquier caso, tenemos pruebas para el comportamiento de la doble estrella , por lo que si alguien quiere enviar pruebas para confirmar que algunos patrones de negación también funcionan (o si alguien encuentra fallas en las pruebas globbing que ya tenemos), sería genial. .

Sin embargo, hay una clara ventaja de tener una opción explícita ignore / exclude . Múltiples ventajas, en realidad:

• menos oscuro
• más fácil de evitar choques con caracteres especiales y reglas de citas de diferentes sistemas operativos
• una lista de inclusión menos una lista de exclusión es más simple en muchos casos que una lista de inclusión con partes negadas

Simplemente quería aclarar que el status quo no está destinado a depender de ningún caparazón en particular. ; ^)

una lista de inclusión menos una lista de exclusión es más simple en muchos casos que una lista de inclusión con partes negadas

Es cierto, y casi me había olvidado de eso 😄

Cualquiera que venga a este problema:

La solución alternativa ahora es usar globs, ya que esto debería ser compatible. Si alguien quiere este comportamiento en particular , envíe un PR.

¿ --exclude opción
No puedo encontrarlo en los documentos .

@ sepo-one Abrí PR para actualizar el documento.
Puede ver todas las opciones disponibles en mocha -h .

Sí, he estado usando una versión antigua de mocha. La opción actualizada y --exclude está ahí.
Los documentos deberían actualizarse de todos modos, supongo.

Gracias @outsideris