If you want to include multiple modules into your describe hierarchy like you are doing in your question, what you are doing is pretty much it, unless you want to write a custom test loader for Mocha. Writing the custom loader would not be easier or make your code clearer than what you already have.
Here’s an example of how I would change a few things. The test subdirectory in this example is organized as:
.
└── 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");
});
});
The importTest function is just to show how it would be possible to handle the repetition of importing multiple modules without having to retype the whole describe(... require... thing every single time. The common module is meant to hold what you need to use in multiple modules of the test suite. I’m not actually using it in top but it could be used there, if needed.
I will note here that the beforeEach will run its code before each and every single test registered with it whether they appear inside the describe in top or they appear in any of the modules imported. With --recursive, the beforeEach code would have to be copied into each module or perhaps you’d have a beforeEach hook in each module that calls a function imported from a common module.
Also, the after hook will run after all tests in the suite. This cannot be replicated with --recursive. If you use --recursive and add the code of after to each module, it will be executed once per module rather than just once for the whole test.
Having all tests appear under a single top heading cannot be replicated by using --recursive. With --recursive each file could have describe("top" but this would create a new top heading for each file.
common.js:
var chai = require("chai");
var options = {
foo: "foo"
};
exports.options = options;
exports.chai = chai;
exports.assert = chai.assert;
Using a module named common like this is something I’ve done in some of my test suites to avoid having to require a bunch of stuff over and over and to hold global read-only variables or functions that don’t keep state. I prefer not to pollute the global object like in thgaskell’s answer because this object is truly global and accessible even in third party libraries your code may be loading. This is not something I find acceptable in my code.
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 () {});