Si desea incluir varios módulos en su describejerarquía como lo está haciendo en su pregunta, lo que está haciendo es prácticamente eso , a menos que desee escribir un cargador de prueba personalizado para Mocha. Escribir el cargador personalizado no sería más fácil ni haría su código más claro de lo que ya tiene.
Aquí hay un ejemplo de cómo cambiaría algunas cosas. El testsubdirectorio en este ejemplo está organizado como:
.
└── test
├── a
│ └── a.js
├── b
│ └── b.js
├── common.js
└── top.js
top.js:
function importTest(name, path) {
describe(name, function () {
require(path);
});
}
var common = require("./common");
describe("top", function () {
beforeEach(function () {
console.log("running something before each test");
});
importTest("a", './a/a');
importTest("b", './b/b');
after(function () {
console.log("after all tests");
});
});
La importTestfunción es solo para mostrar cómo sería posible manejar la repetición de la importación de varios módulos sin tener que volver a escribir todo describe(... require...cada vez. El commonmódulo está destinado a contener lo que necesita usar en varios módulos del conjunto de pruebas. En realidad, no lo estoy usando, toppero podría usarse allí, si es necesario.
Voy a señalar aquí que la beforeEachva a ejecutar su código antes de cada prueba única registrada con itsi aparecen dentro de la describeen top, o que aparecen en cualquiera de los módulos importados . Con --recursive, el beforeEachcódigo tendría que copiarse en cada módulo o tal vez tendría un beforeEachgancho en cada módulo que llama a una función importada de un módulo común.
Además, el aftergancho se ejecutará después de todas las pruebas en la suite. Esto no se puede replicar con --recursive. Si usa --recursivey agrega el código de aftera cada módulo, se ejecutará una vez por módulo en lugar de solo una vez para toda la prueba.
El hecho de que todas las pruebas aparezcan bajo un solo topencabezado no se puede replicar con --recursive. Con --recursivecada archivo podría haberlo hecho, describe("top"pero esto crearía un nuevo topencabezado para cada archivo.
common.js:
var chai = require("chai");
var options = {
foo: "foo"
};
exports.options = options;
exports.chai = chai;
exports.assert = chai.assert;
Usar un módulo llamado commonasí es algo que he hecho en algunas de mis suites de prueba para evitar tener que hacer requireun montón de cosas una y otra vez y mantener variables o funciones globales de solo lectura que no mantienen el estado. Prefiero no contaminar el globalobjeto como en la respuesta de thgaskell porque este objeto es verdaderamente global y accesible incluso en bibliotecas de terceros, su código puede estar cargando. Esto no es algo que encuentre aceptable en mi código.
a/a.js:
var common = require("../common");
var options = common.options;
var assert = common.assert;
it("blah a", function () {
console.log(options.foo);
assert.isTrue(false);
});
b/b.js:
it("blah b", function () {});