Mocha: Want overridable default glob pattern in mocha.opts

[KylePDavis]

I'd like a mechanism for setting an overridable default test file glob pattern so that I can configure mocha.opts to run all test files but also mocha foo_test.js could be used to run a single test file.

The mocha.opts file allows for setting any valid command line arguments so it's nice and simple. For options that can be set more than once these act like default settings since they can be given again on the command line. Unfortunately not everything works this way. In my case the fact that there's no overridable glob pattern is a bit of an issue.

Here are a few ways that we might solve this that I'll toss out for discussion:

1. also look for a require-able config file by default (e.g., test/mocha.opts.js)
   
   
   
   • it would export an Array of args but unlike the regular mocha.opts this one could conditionally change the returned options based on the current state of process.env, process.argv, etc.
   
   
2. support a --default-pattern option to set a glob pattern to be used only if no other pattern was given.

Once we've settled on a preferred method I'll be more than happy to submit a PR to make it happen.

I think option 1 is more flexible but option 2 is more straight-foward. Thoughts?

[boneskull]

What is the contents of your mocha.opts? What are the workarounds?

[KylePDavis]

Here's my mocha.opts file:

--reporter spec
--ui exports
--recursive
test/{,**/}*_test.js

I don't really have a workaround right now. Perhaps I could setup a shell script to wrap mocha for one-off testing but that's a bit clunkier than building this use case into mocha.

[boneskull]

A theoretical workaround is:

1. mv test/mocha.opts test/all.mocha.opts
2. Create test/mocha.opts, the contents of which are:

--reporter spec --ui exports --recursive

1. When you want to run _all_ your tests, execute mocha --opts test/all.mocha.opts
2. When you want to run just _one_ test, execute mocha test/foo_test.js

Regarding your two suggestions:

also look for a require-able config file by default (e.g., test/mocha.opts.js)
it would export an Array of args but unlike the regular mocha.opts this one could conditionally change the returned options based on the current state of process.env, process.argv, etc.

This seems like something trivially handled by a task runner or build tool (make, grunt, gulp, etc.).

support a --default-pattern option to set a glob pattern to be used only if no other pattern was given.

This is more palatable, but I think it's a band-aid on the real issue, which is:

Mocha _concatenates_ non-option arguments specified on the CLI to non-option arguments specified in mocha.opts. This seems weird and broken to me, but fixing it would be a significant breaking change, because I'm sure someone relies on this behavior.

Perhaps I could setup a shell script to wrap mocha for one-off testing but that's a bit clunkier than building this use case into mocha.

I agree. Any feature we add to Mocha is probably going to make things less clunky for somebody. However, generally speaking, if you can trivially get a shell script, make, grunt or gulp to do it for you, it's not an essential feature.

Thanks for asking before sending a PR. If you are interested in changing the "concatenation" behavior as I suggested above, please send a PR against branch 3.0.0. I can't guarantee it'll be merged, but I'd like to see what others think.

[rauschma]

Just in case (I agree with “if you can trivially get a shell script, make, grunt or gulp to do it for you, it's not an essential feature”): I have the same use case.

At the moment, I have two scripts in package.json:

"testall": "mocha --ui qunit --require ts-node/register 'exercises/**/*{_test,_exrc}.{js,ts,tsx}'",
"test": "mocha --ui qunit --require ts-node/register",

I’d prefer to have a single script. For example:

"test": "mocha --ui qunit --require ts-node/register --default 'exercises/**/*{_test,_exrc}.{js,ts,tsx}'",

[medikoo]

I approached same issue, and solution where two scripts should be configured, doesn't sound good.

It seems unnecessarily verbose, and error-prone (same set of options needs to be maintained in two places)