Mocha --grep limits with complex regular expressions

Short answer

Mocha does nothing special with your pattern. --grep builds a plain JavaScript RegExp from the string you pass and calls .test() once per test against the full title (suite names concatenated with the test title). Non-capturing groups (?:...) and lookaheads behave exactly as they do in your Node.js RegExp engine — Mocha adds no parsing layer of its own. --invert just negates that boolean result per test; there is no separate matching path. There is also no documented character limit or complexity threshold: the only hard failure is an invalid pattern, which throws a SyntaxError at startup.

The part that usually surprises people

Because matching runs against the full concatenated title, a pattern can match through a parent suite name. With --invert, a substring that matches an outer suite excludes the entire nested subtree, not just one test. So an inverted pattern like (?:billing|legacy) drops every test under any suite whose title contains either word — including deeply nested children that never mention it themselves. Overlapping-match groups don't create multiple matches here; .test() only asks "does this match anywhere," so nested-block overlap is a non-issue for correctness, only for intent.

Two more scoping facts worth knowing:

• Grep filtering happens after files are loaded. --grep does not skip module loading or top-level code in your spec files — only which runnable tests execute. Root-level hooks still run.
• Lookbehind support ((?<=...)) depends on your Node.js version, not Mocha. Older runtimes will reject the same pattern as invalid.

Performance: backtracking, not discovery

Test discovery cost is unaffected by pattern complexity. The risk is regex backtracking inside a single .test() call, multiplied by the number of tests. Pathological patterns with nested quantifiers — the classic (a+)+$ shape — can take exponential time on non-matching titles, and since the test runs once per test, the slowdown scales linearly with suite size on top of that. Lookaheads and non-capturing groups themselves are cheap; it's unbounded nested repetition that hurts. If your pattern is a few hundred characters of alternations and groups, you will not notice it.

Verify before trusting

Separate regex-engine behavior from Mocha behavior by testing the pattern standalone:

node -e "console.log(new RegExp('(?:billing|legacy)(?!-smoke)').test('billing api retries payment'))"

Then confirm the actual selection without executing tests:

mocha --grep '(?:billing|legacy)(?!-smoke)' --invert --dry-run --reporter min

If you suspect backtracking, time the dry run: time mocha --grep 'pattern' --dry-run. A slow dry run points at the regex; a fast one points elsewhere.

One practical caveat

Shell quoting mangles complex patterns more often than Mocha does. Parentheses, pipes, and backslashes should be single-quoted, or moved into a .mocharc config file where no shell interpretation occurs. If a pattern that works in Node "does nothing" from the CLI, check what the shell actually passed first — that distinction changes the fix, so it's worth confirming before rewriting the regex.