Cómo sabe Mocha qué archivo cargar primero en el conjunto de pruebas

No hay un orden predeterminado para cómo Mocha carga los archivos de prueba.

Cuando Mocha escanea un directorio para encontrar archivos, usa fs.readdirSync . Esta llamada es un contenedor alrededor de readdir(3) , que en sí mismo no garantiza el orden. Ahora, debido a una peculiaridad de implementación la salida de fs.readdir y fs.readdirSync está clasificado en Linux (y probablemente en los sistemas POSIX en general) pero no en Windows . Además, es posible que el comportamiento ordenado en Linux eventualmente se elimine porque la documentación dice fs.readdir es solo readdir(3) y esto último no garantiza el orden. Hay un buen argumento para argumentar que el comportamiento observado en Linux es un error (vea el problema al que me vinculé arriba).

Tenga en cuenta que hay un --sort opción que ordenará los archivos después de que Mocha los encuentre. Pero esto está desactivado por defecto.

El comportamiento que observa se explica no solo por el orden de carga sino también por el orden de ejecución . Esto es lo que sucede:

1. Mocha carga los archivos de prueba y los ejecuta. Entonces, cualquier cosa que esté en el nivel superior de su archivo se ejecuta inmediatamente . Esto significa que el código en test_helper.js se ejecuta de inmediato. Cada llamada a describe inmediatamente ejecuta su devolución de llamada. Sin embargo, las llamadas a it grabar la prueba para su posterior ejecución. Mocha está descubriendo sus pruebas mientras hace esto pero no ejecutando ellos de inmediato.

2. Una vez que se ejecutan todos los archivos, Mocha comienza a ejecutar las pruebas. En este momento, el código en test_helper.js ya se ha ejecutado y su prueba se beneficia de la conexión que ha creado.

Advertencia importante Conectarse a una base de datos es una operación asíncrona, y actualmente no hay nada que garantice que la operación asíncrona en test_helper.js se habrá completado antes de que comiencen las pruebas. Que funcione bien ahora mismo es pura suerte.

Si fuera yo, pondría la creación de la conexión en un before gancho. (Un global before hook que aparece en cualquier archivo de prueba se ejecutará antes que cualquier prueba, incluso las pruebas que aparecen en otros archivos. ) O usar --delay y llame explícitamente a run() para iniciar la suite después de que se garantice la conexión.