Description of the Change

This PR adds support for Node.js's native ESM (ES modules) support. Specifically, up till now, Mocha could only load test files that were CommonJS, and this PR enables it to load test files that are ES modules, and thus enable the test files to import stuff from other ES modules (not to mention other goodies coming up the line, like enabling top-level await, which is an ESM only JS feature).

Note that this support is for Node.js only, and has no connection to browser ESM support. Also, prior to Node v12, there was no or quirky support for ESM, so this support is only for Node v12 and above.

Alternate Designs

This is not a trivial change. The main problem is that loading an ESM is an async operation, and yet the call path to Mocha.prototype.loadFiles is a sync one. Changing the call path would necessitate a semver-major change, which I'm not sure I have the ability to push, so I decided on a design that keeps the signatures of all the functions as they are, unless there is an ESM test file to load, by which time they morph to async functions. So their return type in the signature looks something like Runnner|Promise<Runner>, where Runner is for cases where there are no ESM test files, and Promise<Runner> is for the case there are

This is not a good solution, but it enables us to push this change without it being semver-major, and once there is a decision to change to semver-major, the signature change and code change that does this is trivial.

If y'all decide that this PR can change the major version of Mocha, I can fix it so that the signatures change and the weirdness goes away.

Another not insignificant change was the error path. In some cases, errors found by Mocha were synchronous, i.e. they occur during the yargs.parse phase, which throws the error. But, because the call path to loadFiles could be asynchronous, I changed the command handler (in lib/cli/run.js) to be async (i.e to return a Promise). This means that errors (such as bad tap versions) are no more synchronous, and will always arrive at the fail yargs handler (in lib/cli.js). To make them look like the old errors, I changed the code there. No tests fail now, so it seems OK, but please check this in the review.

Why should this be in core?

I'm assuming this is obvious: it has to change Mocha.prototype.loadFiles to be async. There is the esm module that simulates ESM in userland, but native support has to be async. And native support is crucial if the developer's code is running using Node's native ESM support.

Benefits

Developers starting to write Node.js code in ES modules will benefit by being able to write their tests using ESM too, and not have to dynamically import their ES modules using dynamic import (aka await import), which is a hassle and a kludge.

Possible Drawbacks

This may impact code using Mocha's API, as we are changing the signature (even if not in the short run, definitely in the long run). Also, error handling has subtly changed, and this may impact error handling reporting in ways I cannot know.

Applicable issues

This is currently an enhancement (minor release), that should be turned in the future into a semver-major, as described in the "Alternate Designs" section.

Limitations

• "Watch" mode does not currently work with ESM, as there is currently no way to remove an ESM module from Node.js' module cache. We would have to either wait for it to be implemented in Node (slim chance, IMHO), or refactor watch mode to use subprocesses every time a change is detected.
• Module-level mocks via libs like proxyquire or rewiremock or rewire cannot work. If you are using these libs or similar, hold off on using ESM for your test files.. This is not inherently a limitation in Mocha, but rather a limitation in Node's ESM support, which will probably be rectified sometime in Node v13.
• ESM is not supported for custom reporters, nor is it supported for custom interfaces.

• If a runnable returns a duck-typed promise, i.e. an object with a then method, it gets treated as an async test, with success if the promise is fulfilled and failure if it is rejected (with the rejection reason as the error).
• Includes tests both of new functionality and some to show that introducing this doesn't break any old functionality.

Would really appreciate merging this! I tried to stick as close as possible to the existing style. We <3 Mocha but also <3 promises.

This:

before(done => {
    return Promise
        .all([])
        .then(() => Model.insert(...)) // Bookshelf model returning a Bluebird Promise
        .then(() => done())
        .catch(done)
})

will result in an error Error: Resolution method is overspecified. Specify a callback *or* return a Promise; not both.

Docs say:

In Mocha v3.0.0 and newer, returning a Promise and calling done() will result in an exception, as this is generally a mistake:

The model call is resolving with a Promise.<Object> of the newly inserted entry, however if I omit .then(() => done()) then the test timeouts.

(..or maybe Mocha 4. I don't know.)

@mochajs/mocha + everyone,

I mentioned this in the mochajs/maintainers room on Gitter, but since it appears people aren't using Gitter much, I'll repeat it here:

Pitch

Mocha's old. What's cool about that is that we know what's wrong with it. And indeed, it has problems which make certain issues difficult to address. The major issue is "plugins". Others include (but are not limited to):

• The whole thing is written in ES5
• The core is bloated (modularize it)
• Test files are not node-able
• No parallelism
• Lack of automated browser tests
• Inability to leverage domains
• Patchwork "diff" support
• Too many hand-rolled shims/polyfills
• Too much hand-rolled stuff in general which should be replaced by 3p libs that do it better
• "Configuration" is tightly coupled with the CLI
• Programmatic usage is undefined
• Multiple executables = pain
• Various instances of callback hell
• Poor support for writing 3rd-party reporters and interfaces

It's my opinion that any attempt to address these problems in an iterative fashion is a fool's errand. Components are too tightly coupled; each item above, if taken in the context of the current codebase, is a major undertaking. I propose we rewrite Mocha from scratch.

Plan

Mocha should made of plugins--all the way down. It should come with a default interface and a default reporter, but little else--Mocha's business is running tests and reporting the output. This is what it does well, and this is what the core should be.

From the current version of Mocha, we'd retain:

• The "simple, flexible, fun" motto. Mocha should remain unopinionated; its core should be simple. We would split some portion of the existing functionality into plugins (separate modules) which can be easily included if necessary.
• The interface APIs. Users should not have to modify their tests.
• Support for "deprecated" APIs would move to plugins or separate modules. For example:
  • I'd like to move to using JSON/YAML/JS .mocharc file(s) instead of mocha.opts. We would retain the mocha.opts functionality in a plugin; package mocha-opts-plugin, for example.
  • --watch, which should be handled by a plugin or another executable entirely.
  • Command-line flags to node should be handled by node itself--either by executing mocha with node, or using node-able tests.
  • The CLI itself should move to a package mocha-cli, as not everyone uses it.
• Some portion of the E2E tests should be retained to guide adherence to the API.

For libraries and tools which consume Mocha (I'm thinking stuff like JetBrains Mocha reporter, Wallaby.js, mochify, karma-mocha, any Grunt/Gulp plugin which executes _mocha), we must keep lines of communication open to ensure a smooth transition. Ideally, these tools should use the resulting programmatic interface instead of forking processes!

We should supply a Yeoman generator for Mocha plugins, which would provide starting points and boilerplate for Browserify (since certain plugins will need to run in a browser).

Conclusion

If you guys are buying what I'm selling, I think the best thing to do is just start coding. The direction is clear, and the requirements are known. Let's create a prototype and take it from there. When the dust settles, we can address specific areas of concern, and begin to deprecate whatever needs deprecating. And start documenting. An upgrade to v3 shouldn't require the user to do much more than install an extra package or two.

cc @segrey @mantoni @ArtemGovorov @vojtajina @maksimr @dignifiedquire

Hi!

This pull request adds support for multiple reporters.

One of my use cases for multiple reporters is described in my recent post on mocha's google group. To sum it up, I'm using mocha to run tests on a Bamboo instance, and I use the xunit-file reporter to create a file that can be parsed by Bamboo to display tests results. However, I also need to send tests reports to a CouchDB instance that doesn't accept xml files, but JSON documents. Right now, I'm running the tests twice: first with the xunit-file reporter, and then with the mocha-json-file-reporter to generate the xunit file and the json document. This has a number of cons like slowing down the whole process, and even sometimes not generating the exact same results, which can lead to a lot of confusion.

These changes allow me to run both reporters at the same time, and I think being able to run more than one reporter at a time can be useful to others. All the tests seem to run fine.

Prerequisites

• [x] Checked that your issue isn't already filed by cross referencing issues with the common mistake label
• [x] Checked next-gen ES issues and syntax problems by using the same environment and/or transpiler configuration without Mocha to ensure it isn't just a feature that actually isn't supported in the environment in question or a bug in your code.
• [x] 'Smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, your usage of Mocha, or Mocha itself
• [x] Ensured that there is no discrepancy between the locally and globally installed versions of Mocha. You can find them with: node node_modules/.bin/mocha --version(Local) and mocha --version(Global). We recommend avoiding the use of globally installed Mocha.

Description

Before I start, there are already some closed issues regarding this topic but as the prerequisites have changed I would like to start a new attempt.

Now that node supports running EMCAScript modules (yes, I know it is experimental) it would be great to see mocha to work in conjunction with mjs test definitions.

Steps to Reproduce

I have a very simple test

describe('Test', function () {
});

Which i have saved as test.js and test.mjs

Expected behavior: I would like both tests to show

- test/test.js 
  0 passing (1ms)
(node:70422) ExperimentalWarning: The ESM module loader is experimental.

Actual behavior: While the js test works, the mjs test gives me

- test/test.mjs 
module.js:658
    throw new errors.Error('ERR_REQUIRE_ESM', filename);
    ^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /Users/dgehl/Repositories/LOreal/code/ecom-lora/test/frontend/components/global/test.mjs

Reproduces how often: 100%

Versions

node --version - v8.5.0 mocha --version - 3.5.3

Additional Information

I think that this might be that mocha's runner is using commonjs and nodejs' current implementation disallows to use ECMAScript modules from a commonjs context.

Please don't reply with "use a transpiler", I want to explicitly not use one.

Edit: in an earlier version I accidentally used jsx instead of mjs.

I would like the ability to provide an exclusion pattern so that I can only test files that match my test file pattern. This would allow data files to coexist with test files so long as they follow a reasonable pattern.

I think this would be simply providing an option that sets ignore option in glob.

Thoughts? I can make a PR for it real quick if you'd like.

I would like some function like skipTest() and skipSuite() that would allow me to skip a test or suite without failing it.

If you are in suiteSetup() then you could skip the suite if you are in test() then you could skip the rest of the suite or the test if you are in setup() then you could skip the rest of the suite or the test if you are in tearDown() then you could skip rest of the suite if you are in suiteTearDown() then you could not skip either

Description of the Change

Now that Mocha supports ESM test files, I found that importing Mocha in ESM files is awkward, if you're like me and don't like to rely on the it/before/... globals. So, if you used to do this in CJS:

const {it, before} = require('mocha')

You'd like to do this in ESM:

import {it, before}  from 'mocha'

But you can't, because Mocha doesn't have an ESM entry point, and relies on the fact that CJS files can be imported, but only using default import. So you have to do this:

import mocha  from 'mocha'
const {it, before} = mocha

This PR exports an ESM entry point so that you can use named exports in a natural manner when importing Mocha itself.

The way it does this is to add an exports section to the package.json, as described in the Node.js documentation for exports. This exports has a "conditional export" that defines separate entry points for ESM and CJS.

Note that exports affects both ESM and CJS, so we should be careful (see ramifications below).

Alternate Designs

There is no alternate design, as this is the only way to do what are called dual-mode packages in ESM.

Why should this be in core?

Well, where else can it be? ☺️

Benefits

Importing mocha in a manner that is natural for ESM.

Possible Drawbacks

Based on the case of is-promise, theoretically this can break anybody using Mocha, because adding exports: ... to package.json affects CJS too! It means that the only entrypoints allowed (in CJS and ESM) are the ones defined in the exports .

Which is why I added "./": "./" to the exports, which says to Node.js: allow any deep importing such as require("mocha/foo/bar") in the case that somebody, somewhere, is using that. This was also the solution used by is-promise.

But this has not been tested, as Mocha doesn't have an E2E test that checks that the package is OK. The way to write this test is to do an npm pack that creates a tar.gz, and then create a package that has as a dependency that tar.gz, and then test whatever we want in there. This ensures that the package as a package (without the original source code) is OK. I did not add this test, as it feels way out of scope of this little addition.

Applicable issues

:warning: Before you read the suggested tagging API has changed since the initial proposal, see new comments further down

As discussed in #928, this is a tentative PR for tagging support in the bdd interface. I hope this is not against the guidelines (PR for a new feature), but it will be easier to discuss what's feasible with some visibility on the code changes.

• you can optionally pass an array of tags as the first argument to describe and it
• by default, all tests always run
• you can specify --tags to run a subset of the tests
• tests that don't match the filter are marked as pending

describe('my service', function() {
  it('test 1', function() {});
  describe(['integration'], 'backend connectivity', function() {
    describe(['fast'], 'quick tests', function() {
      it('test 2', function() {});
    });
    it(['slow'], 'test 3', function() {});
  });
});

• mocha runs everything
• mocha --tags "not:integration" runs test 1
• mocha --tags "is:integration" runs tests 2 and 3
• mocha --tags "is:integration not:slow" runs test 2

You can also programmatically update the filter with

if (/* out of business hours */) {
  require('mocha').options.tags.add('not:backend');
}

If this looks good, happy to look into how to unit test & document it. Cheers

I've read through https://github.com/visionmedia/mocha/issues/802 and https://github.com/visionmedia/mocha/issues/590

I believe I've found where the issue lies: Snippet from base.js https://github.com/visionmedia/mocha/blob/master/lib/reporters/base.js

exports.colors = {
    'pass': 90
  , 'fail': 31
  , 'bright pass': 92
  , 'bright fail': 91
  , 'bright yellow': 93
  , 'pending': 36
  , 'suite': 0
  , 'error title': 0
  , 'error message': 31
  , 'error stack': 90
  , 'checkmark': 32
  , 'fast': 90
  , 'medium': 33
  , 'slow': 31
  , 'green': 32
  , 'light': 90
  , 'diff gutter': 90
  , 'diff added': 42
  , 'diff removed': 41
};

var color = exports.color = function(type, str) {
  if (!exports.useColors) return str;
  return '\u001b[' + exports.colors[type] + 'm' + str + '\u001b[0m';
};

So the color function takes in a type and uses the conversion table above to get the ANSI escape color. A chart can be found here: http://en.wikipedia.org/wiki/ANSI_escape_code#CSI_codes

As you can see:

Seems to be a closed-source terminal from IBM AIX. I believe nobody is using mocha on it. (Correct me if I'm wrong)

Furthermore, I found the ECMA specification: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf Here is page 62:

Color 90-99 are not in the specification. Most terminals wouldn't care implementing these colors correctly and god knows what color they'll fall back into. And not everyone uses iTerm2, which has a contrast setting. Please use color 30-37, if you want increased intensity then \u001b[30;1m would use the intense variant. I think users are only responsible for configuring their terminals so the 16 colors look great on their bg/fg colors. So please don't just say "It's the theme's fault" and close the issue. It's mocha's problem not using color from the standard palette.

I use deepdash since half-year and dont understand why "export thing" is related to the test ... or why it apply some specefic strict ts-rules for running tests.

> mocha -r ts-node/register src/Manipulation/Node/string/test.spec.ts


Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './es/eachDeep' is not defined by "exports" in C:\WORKBRENCH\PACKAGE\LordTs\node_modules\deepdash\package.json
    at new NodeError (node:internal/errors:393:5)
    at exportsNotFound (node:internal/modules/esm/resolve:295:10)
    at packageExportsResolve (node:internal/modules/esm/resolve:631:9)
    at resolveExports (node:internal/modules/cjs/loader:538:36)
    at Function.Module._findPath (node:internal/modules/cjs/loader:607:31)
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:1025:27)
    at Function.Module._resolveFilename.sharedData.moduleResolveFilenameHook.installedValue [as _resolveFilename] (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\@cspotcode\source-map-support\source-map-support.js:811:30)
    at Function.Module._load (node:internal/modules/cjs/loader:885:27)
    at Module.require (node:internal/modules/cjs/loader:1105:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (C:\WORKBRENCH\PACKAGE\LordTs\src\dontUnderstant.ts:1:1)
    at Module._compile (node:internal/modules/cjs/loader:1218:14)
    at Module.m._compile (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1618:23)
    at Module._extensions..js (node:internal/modules/cjs/loader:1272:10)
    at Object.require.extensions.<computed> [as .ts] (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1621:12)   
    at Module.load (node:internal/modules/cjs/loader:1081:32)
    at Function.Module._load (node:internal/modules/cjs/loader:922:12)
    at Module.require (node:internal/modules/cjs/loader:1105:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (C:\WORKBRENCH\PACKAGE\LordTs\src\Manipulation\Utils\color\operation.ts:2:1)
    at Module._compile (node:internal/modules/cjs/loader:1218:14)
    at Module.m._compile (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1618:23)
    at Module._extensions..js (node:internal/modules/cjs/loader:1272:10)
    at Object.require.extensions.<computed> [as .ts] (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1621:12)   
    at Module.load (node:internal/modules/cjs/loader:1081:32)
    at Function.Module._load (node:internal/modules/cjs/loader:922:12)
    at Module.require (node:internal/modules/cjs/loader:1105:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (C:\WORKBRENCH\PACKAGE\LordTs\src\Manipulation\Utils\color\index.ts:3:1)
    at Module._compile (node:internal/modules/cjs/loader:1218:14)
    at Module.m._compile (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1618:23)
    at Module._extensions..js (node:internal/modules/cjs/loader:1272:10)
    at Object.require.extensions.<computed> [as .ts] (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1621:12)   
    at Module.load (node:internal/modules/cjs/loader:1081:32)
    at Function.Module._load (node:internal/modules/cjs/loader:922:12)
    at Module.require (node:internal/modules/cjs/loader:1105:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (C:\WORKBRENCH\PACKAGE\LordTs\src\Manipulation\Node\number\convert.ts:1:1)
    at Module._compile (node:internal/modules/cjs/loader:1218:14)
    at Module.m._compile (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1618:23)
    at Module._extensions..js (node:internal/modules/cjs/loader:1272:10)
    at Object.require.extensions.<computed> [as .ts] (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1621:12)   
    at Module.load (node:internal/modules/cjs/loader:1081:32)
    at Function.Module._load (node:internal/modules/cjs/loader:922:12)
    at Module.require (node:internal/modules/cjs/loader:1105:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (C:\WORKBRENCH\PACKAGE\LordTs\src\Manipulation\Node\number\index.ts:2:1)
    at Module._compile (node:internal/modules/cjs/loader:1218:14)
    at Module.m._compile (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1618:23)
    at Module._extensions..js (node:internal/modules/cjs/loader:1272:10)
    at Object.require.extensions.<computed> [as .ts] (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1621:12)   
    at Module.load (node:internal/modules/cjs/loader:1081:32)
    at Function.Module._load (node:internal/modules/cjs/loader:922:12)
    at Module.require (node:internal/modules/cjs/loader:1105:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (C:\WORKBRENCH\PACKAGE\LordTs\src\Manipulation\Node\string\random.ts:3:1)
    at Module._compile (node:internal/modules/cjs/loader:1218:14)
    at Module.m._compile (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1618:23)
    at Module._extensions..js (node:internal/modules/cjs/loader:1272:10)
    at Object.require.extensions.<computed> [as .ts] (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1621:12)   
    at Module.load (node:internal/modules/cjs/loader:1081:32)
    at Function.Module._load (node:internal/modules/cjs/loader:922:12)
    at Module.require (node:internal/modules/cjs/loader:1105:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (C:\WORKBRENCH\PACKAGE\LordTs\src\Manipulation\Node\string\index.ts:2:1)
    at Module._compile (node:internal/modules/cjs/loader:1218:14)
    at Module.m._compile (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1618:23)
    at Module._extensions..js (node:internal/modules/cjs/loader:1272:10)
    at Object.require.extensions.<computed> [as .ts] (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1621:12)   
    at Module.load (node:internal/modules/cjs/loader:1081:32)
    at Function.Module._load (node:internal/modules/cjs/loader:922:12)
    at Module.require (node:internal/modules/cjs/loader:1105:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (C:\WORKBRENCH\PACKAGE\LordTs\src\Manipulation\Node\string\test.spec.ts:2:1)
    at Module._compile (node:internal/modules/cjs/loader:1218:14)
    at Module.m._compile (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1618:23)
    at Module._extensions..js (node:internal/modules/cjs/loader:1272:10)
    at Object.require.extensions.<computed> [as .ts] (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\ts-node\src\index.ts:1621:12)   
    at Module.load (node:internal/modules/cjs/loader:1081:32)
    at Function.Module._load (node:internal/modules/cjs/loader:922:12)
    at Module.require (node:internal/modules/cjs/loader:1105:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.exports.requireOrImport (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\mocha\lib\nodejs\esm-utils.js:53:16)
    at async Object.exports.loadFilesAsync (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\mocha\lib\nodejs\esm-utils.js:100:20)     
    at async singleRun (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\mocha\lib\cli\run-helpers.js:125:3)
    at async Object.exports.handler (C:\WORKBRENCH\PACKAGE\LordTs\node_modules\mocha\lib\cli\run.js:370:5)

when execute this command

mocha -r ts-node/register src/Manipulation/Node/string/test.spec.ts

if it found 0 test then it exit with a correct message so I suppose that Mocha found the test file but cannot execute it beacause of deepdash (or more ?).

my tests concerned a string:

import { makeSuiteTest } from "../../../MBT";
import {
    randomStr, analysPassword, capitalizeWord, insertAt, isCorrectString, replaceAll, replaceChainAll,
    strTextStruct
} from "./";

makeSuiteTest(
    {
        arrange: data => capitalizeWord(data),
        nameObject: 'capitalizeWord',
        bundleTests: [
            {
                type: "Commun",
                tests: [
                    { operande: "equal", data: "captain", expected: "Captain" },
                    { operande: "equal", data: "commandant ivovovna", expected: "Commandant ivovovna" }
                ],
            },
            {
                type: "Alternate",
                tests: [
                    { operande: "equal", data: "3", expected: "3" }
                ],
            }
        ]
    }
);


makeSuiteTest(
    {
        arrange: data => insertAt(data.str, data.strAdd, data.position),
        nameObject: 'insertAt',
        bundleTests: [
            {
                type: "Commun",
                tests: [
                    { operande: "equal", data: {str:"elune", strAdd:"Fr", position:0}, expected: "Frelune" },
                    { operande: "equal", data: {str:"elune", strAdd:"shak", position:4}, expected: "elunshake" }
                ],
            },
        ]
    }
);

makeSuiteTest(
    {
        arrange: data => replaceAll(data.value, data.search, data.replacement),
        nameObject: 'replaceAll',
        bundleTests: [
            {
                type: "Commun",
                tests: [
                    { operande: "equal", data: {value:"elune", search:"e", replacement:"bi"}, expected: "bilunbi" },
                    { operande: "equal", data: {value:"elunelun", search:/lun/, replacement:""}, expected: "ee" }
                ],
            },
        ]
    }
)

Prerequisites

• [x] Checked that your issue hasn't already been filed by cross-referencing issues with the faq label
• [x] Checked next-gen ES issues and syntax problems by using the same environment and/or transpiler configuration without Mocha to ensure it isn't just a feature that actually isn't supported in the environment in question or a bug in your code.
• [x] 'Smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, your usage of Mocha, or Mocha itself
• [x] Ensured that there is no discrepancy between the locally and globally installed versions of Mocha. You can find them with: node_modules/.bin/mocha --version(Local) and mocha --version(Global). We recommend that you not install Mocha globally.

Description

I'm unit testing a code which deals with global variables (intended).

Mocha leaks detection worked well and detected that I was leaking my unit test global variables.

I then proceeded to use hooks in attempt to clean the global scope. However it seems mocha's leak detection is running BEFORE the hooks, making it impossible to clean the global scope in hooks. I believe that's not what we want.

Steps to Reproduce

describe('test', function() {
	function _clean_global_scope() {
		delete globalThis._foo
	}
	before(_clean_global_scope)
	afterEach(_clean_global_scope)

	it('should set the global variable', () => {
		globalThis._foo = 33
		expect(globalThis._foo).to.equal(33)

		// _clean_global_scope() // if we uncomment this line, the test pass
	})
})

Expected behavior: [What you expect to happen] No error.

Actual behavior: [What actually happens] Error: global leak(s) detected: '_foo'

Reproduces how often: [What percentage of the time does it reproduce?] 100%

Versions

• The output of mocha --version and node_modules/.bin/mocha --version: 10.1.0
• The output of node --version: 18.12.1

Additional Information

If I manually call _clean_global_scope() at the end of the unit test, the leak is not reported. However the point of the hooks is to avoid this duplication.

Also thanks for this trusty tool that I'm using for so many years!

Is your feature request related to a problem or a nice-to-have?? Please describe. I wanted to start using parallel mode. In serial mode I have a before() root hook that initializes the database and an after() root hook that does some teardown. To use parallel mode I want to fan out into one database per MOCHA_WORKER_ID, so if I have two jobs, I just need to setup/teardown a database for MOCHA_WORKER_ID=0 once and setup/teardown a database for MOCHA_WORKER_ID=1 once. The same goes for isolating redis instances used by my tests. Would be nice if each worker could just start its own redis container, and stop it at the end. It feels like this should have been easy. Instead, it's been a complete hassle. Even with code changes, I can't figure out any clean way to do it.

Describe the solution you'd like I'd like to be able to use --file (or something) to pass files with before/after root hooks to every worker, and have them run once per worker. This would have made migrating to parallel mode a total breeze.

The only options Mocha gives me right now are once per file (root hook plugins) or once only (global fixtures).

Describe alternatives you've considered I can wrap beforeAll with once() to initialize a resource associated with the worker process. However, I can't wrap afterAll with once() because that will run after the first test file, not after all test files in the worker.

I even tried making each test file import the file with my before/after hooks. But they only seemed to get attached to tests in the first file in parallel mode. It's hard to imagine a reason why it has to behave that way.

Then I thought about making a global fixture that initializes all the databases, but I don't see any documented way to ask mocha how many jobs it will run from the global fixture...argh!

Prerequisites

• [x] Checked that your issue hasn't already been filed by cross-referencing issues with the faq label
• [x] Checked next-gen ES issues and syntax problems by using the same environment and/or transpiler configuration without Mocha to ensure it isn't just a feature that actually isn't supported in the environment in question or a bug in your code.
• [x] 'Smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, your usage of Mocha, or Mocha itself
• [x] Ensured that there is no discrepancy between the locally and globally installed versions of Mocha. You can find them with: node_modules/.bin/mocha --version(Local) and mocha --version(Global). We recommend that you not install Mocha globally.

Description

Running mocha with --fail-zero and --delay options, and calling run(). The exit code is always 1, even when some tests did run.

Steps to Reproduce

I created a gist with the files used in the examples below: https://gist.github.com/tonimellodic/525d29054744ca6d602145b81eb57e80

Expected behavior: Running with --fail-zero and --delay produces exit 0 when at least one test run.

Actual behavior: Running with --fail-zero and --delay always produces exit 1.

Running with --fail-zero only:

% npx mocha --fail-zero test/no-delay.js     

  No delay example
    ✔ runs a test

  1 passing (3ms)

% echo $?
0

Running with --fail-zero and --delay:

% npx mocha --fail-zero --delay test/delay.js

  Delay example
    ✔ runs a delayed test

  1 passing (5ms)

% echo $?
1

Reproduces how often: Always

Versions

mocha 10.1.0 node 16.13.1 MacOS 12.6.1 zsh shell

Prerequisites

• [x] Checked that your issue hasn't already been filed by cross-referencing issues with the faq label
• [x] Checked next-gen ES issues and syntax problems by using the same environment and/or transpiler configuration without Mocha to ensure it isn't just a feature that actually isn't supported in the environment in question or a bug in your code.
• [x] 'Smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, your usage of Mocha, or Mocha itself
• [x] Ensured that there is no discrepancy between the locally and globally installed versions of Mocha. You can find them with: node_modules/.bin/mocha --version(Local) and mocha --version(Global). We recommend that you not install Mocha globally.

Description

I'm not quite sure if this should be a feature request or bug report

Mocha not print anything with my project without DEBUG=*. The logs in debug mode isn't helpful for find out where is the problem It's exit immediately after Mocha#loadFilesAsync emit the first test file.

It's seems there is some problem with my source files. Mocha will pass a test file when it's empty. But it's not important. I think mocha need log something helpful.

So below is just for people interested. Not relating to this issue. I'm using mocha on a typescript + ts-node + swc. It's fine at a commit. But output nothing at another commit. It's weird caused by move the test files.

Edit: I've tried to add two lines before https://github.com/mochajs/mocha/blob/master/lib/nodejs/esm-utils.js#L7. But the second one isn't print anything. I think it is the problem. But there isn't anything being catched. I don't know how to debug the import behavior. But it's seems something in deeper instead of mocha :(

console.log(url.pathToFileURL(file))
console.log(await import(url.pathToFileURL(file)))
return await import(url.pathToFileURL(file)) // L7

Edit: After test. The exit happened after I move the types from utils.ts to default-extractors.ts. And fixed after move the types from default-extractors.ts to another file

Steps to Reproduce

Clone project: https://github.com/SettingDust/article-extractor/commit/62ec19f72cde4df533ede66512e03efcc3d9f368 Run tests

Expected behavior: Log something when Mocha#loadFilesAsync failed to load a test file. Such as the file name.

Actual behavior: Nothing print

Debug log: https://pastes.dev/Bt5vI875iS

Reproduces how often: 1/1

Versions

• The output of mocha --version and node_modules/.bin/mocha --version: 10.1.0
• The output of node --version: 18.12.1 and 16(Tried, but uninstalled because of useless)
• Your operating system
  • name and version: Windows 11 22H2
  • architecture (32 or 64-bit): 64
• Your shell (e.g., bash, zsh, PowerShell, cmd): PowerShell
• Any third-party Mocha-related modules (and their versions):
• Any code transpiler (e.g., TypeScript, CoffeeScript, Babel) being used (and its version):
  • @swc/core 1.3.18
  • typescript 4.9.3
  • ts-node 10.9.1

Is your feature request related to a problem or a nice-to-have?? Please describe.

Right now mocha --parallel works by using a specific number of workers and running tests in parallel across these workers. This means a single worker ends up running many test suites in the same process. The main reason we wanted to parallelize tests is not for speed but to isolate tests, which is not the case even in parallel.

Describe the solution you'd like

It would be great to have a mode where the tests could be completely isolated so that a new worker is started for every file, thus avoiding side-effects from previous files.

Describe alternatives you've considered

Usually, the alternative is to write code and tests in a way that avoids side-effects so that every test can be run in the same process without issues. However, for our case, we patch and instrument many things that are irreversible, like enabling async_hooks, patching the module system, patching dependencies as they are imported, adding ESM loaders, etc. This makes it basically impossible to avoid side-effects, so our only option is to ensure test isolation.

Additional context

I wasn't able to find a way to do this with the latest version of Mocha, but please let me know if there is already a way to do this.