--dry-run option

[joshski]

Adds a --dry-run option, which makes all tests pass without actually running any.

This is sometimes useful as a developer, but also allows other tools to list tests without running them.

[travisjeffery]

isn't necessary imo

[dbkaplun]

👍 this option is useful for listing all tests, I think this would be a good addition.

[joshski]

I was building a tool that needed it. Can't share the code, but there is a fairly straightforward alternative if you need it too: define global "describe" and "it" functions (etc.) -- each one like a spy, then require all your tests.

[Droogans]

👍

I can think of an example of where this might be helpful:

In your team's CI environment, do mocha --dry-run > test/overview.txt, and publish that with your team's most recent prod push to forward along to stakeholders who need to know what's being tested, what your coverage is, etc.

[volgar1x]

This needs to be merged.

[clickthisnick]

Useful for listing the amount of tests should be run, then if you run tests in parallel across multiple containers assert all the tests did in fact run

[raistlin]

Why is this feature still not merged?

[lukewis]

Another use case for this feature:
I split my tests into two categories "unit" tests (which run with the CI build) and "proto" or "integration" tests which can be run on demand. Typically proto or integration tests are run one at a time and often require database interaction or other configuration. We use them mostly to test our data access logic. Due to the nature of these tests, running the wrong test can be a real problem (manipulating a database unexpectedly, connecting to the wrong environment, etc).

I have two npm scripts to handle this scenario:

"scripts": {
    "proto": "mocha dist/tests/proto/**/*.proto.js",
    "test": "mocha dist/tests/**/*.spec.js"
}

I use mocha's "only" feature to cherry pick specific tests to run. However, I often forget to remove the "only" flag when I'm done. Finding which tests have specified "only" can be rather tediuous. I'm always very hesitant to hit the "go" button until I'm CERTAIN that I'm only running ONE SPECIFIC TEST. The "--dry-run" flag would give me confidence that I'm only going to run the test I intend to run.

[Droogans]

@lukewis although a dry run option would help here, consider adding a pre-commit hook that looks for .only in your test files.

FILES_PATTERN='(app|test).+\.js(\..+)?$'
FORBIDDEN='console.log(\|describe\.only\|it\.only'

# Quit if no relevant files are being checked in.
FILES=$(git diff --cached --name-only | grep -Ec $FILES_PATTERN)
if [ "$FILES" = "0" ]; then
    exit 0
fi

cd "$(git rev-parse --show-toplevel)/"

git diff --cached --name-only | \
    grep -E $FILES_PATTERN | \
    GREP_COLOR='37;41' xargs grep --color --with-filename -n $FORBIDDEN && \
    echo 'Please remove debugging statements before commiting.' && exit 1

This is meant to run on Mac or Linux. Sorry, no Windows.

[lukewis]

Very interesting, @Droogans , thanks for sharing (especially appreciate the code sample)! I hadn't used any git hooks before, so researching them has been quite eye-opening. It feels like they are "really close" to being super useful! I wish it was easier to do things like

• Commit your hooks as part of the repository (so that an entire team shares the same hooks)
• Create cross-platform hooks (in nodejs or similar) so Windows users aren't left behind

I know there are solutions to these problems, but it feels like it adds a moderate amount of complexity to the repository (git is already fairly complex by itself!). In the end, I'm still on the fence if hooks are a good fit to solve this problem (though I really appreciate the creativity!). I do love the "simplicity" of just having a --dry-run option, and I too can appreciate your suggested use case of creating a "report" of the active tests.

[JamieMcNaught]

Sorry, but this would be really bloody useful.

We've currently got mocha seriously misbehaving following an upgrade and the ability to do a dry run to list all the tests to make sure we've not got require issues or some other issue with the test setup rather than the tests themselves would be a godsend.
Would also be useful for easily getting a list of all our tests - no, grepping the codebase wont do as a lot of our tests are generated programatically and grep'ing just won't provide a true list.

[wyckster]

Came across this today looking for something similar. I wanted to simply list all the names of the tests so that I could externally partition the list and run the tests in batches on different machines. For example, dispatch all the A-M tests to run on one machine/process and dispatch all the N-Z tests to run on a second machine/process (Obviously I would partition more intelligently in the real world - but you get my point.)

If the --dry-run were just a --list then I could write a test runner that would first call mocha to generate the list of tests, then partition the list, then dispatch mocha to run on N worker machines, giving each of them 1/Nth of the tests to run. Then aggregate their results/artifacts and finally report a unified pass/fail result to the continuous integration system.

I don't know how to get started if I can't get a list of all the tests though.

[sh3raawii]

Can we re-open this PR since it's indeed extremely useful ?!

[sh3raawii]

Guys i created a package for this, go check it out
https://github.com/sh3raawii/mocha-decaf

[digeff]

👍

[gabssnake]

Still relevant