Would be nice if mocha sets the NODE_ENV variable to 'test'

[Cowboy-coder]

Pretty handy if different middlewares / configs etc. in Express or such is needed when running the test suite.

[tj]

i dont want to force it on anyone, but you can easily just do NODE_ENV=test mocha etc or add it a makefile etc

[Cowboy-coder]

fair enough!

[logicalparadox]

One of the advantages of not having this set by default is when writing tests for apps that run in many different environments. For example, one app that I develop has an additional set of tests that it runs on a staging server (NODE_ENV=staging) when it has access to production quality data. As the DB config and the logging transports all depend on that env variable, mocha overwriting it would cause some issues.

-1 on this.

[Cowboy-coder]

Just to clarify I meant an implementation where NODE_ENV would default to test but could be overwritten. However setting it through a Makefile is good enough for me. I just don't want to type NODE_ENV=test mocha everytime :)

[tj]

for sure. i always have make test since i dont even really want to go look up the mocha config or anything, mocha.opts gets around most of that but still

[jaskiern]

A possible workaround, assuming you're running mocha from the same terminal every time, would be:
$ export NODE_ENV=test
$ mocha

NODE_ENV will persist through every command that runs in that window.

[naholyr]

Note: I made a dumb plugin for that. It's a dead simple one-line module, but doing the job in mocha.opts felt like the best way for me.

If a --env command line option would exist, we wouldn't even need this one-line module to do the trick in mocha.opts :)

[jwalton]

+1 for a --env option. Or even a --define option that would let me set a global variable.

[travisjeffery]

nah. why add mocha test --env SOME_VAR=whatever when there's SOME_VAR=whatever mocha ?

[jwalton]

Because then when I want to run one test, I have to type:

SOME_VAR=whatever ./node_modules/.bin/mocha test/foo/barTest.coffee

instead of putting --env SOME_VAR=whatever in the mocha.opts and then typing:

./node_modules/.bin/mocha test/foo/barTest.coffee

and I a very lazy. ;)

[travisjeffery]

export the var in your shell config would work the same as mocha.opts

[jwalton]

Yes, although then I need to make sure everyone else on my team exports it in their shell while they are running tests, and not export it while they are not running tests, which is a bit painful.

In my case I'm using it to suppress logging (since they mess up the pretty output from Mocha). So it's nothing essential.

[naholyr]

Oh yeah it seems like the perfect way to do it, let's put NODE_ENV=test in
bashrc :')

The only sane way is using mocha.opts, use case has been pretty clearly
stated here :
https://github.com/lmtm/node-env-test/blob/master/README.md#why

Given that conclusion, the real question is a dumb plug-in enough or a
simple cli arg better?
Le 6 sept. 2014 01:33, "Travis Jeffery" notifications@github.com a écrit :

export the var in your shell config would work the same as mocha.opts

—
Reply to this email directly or view it on GitHub
#185 (comment).

[naholyr]

In my case I'm using it to suppress logging (since they mess up the
pretty output from Mocha). So it's nothing essential.

Note the usual case is about fixtures, deleting local database because of
an unset environment variable can become a big deal ^^
Especially if a misinformed operational runs unit tests "just to check" and
empties production database. This is a lot of bad luck, but I'm sure this
happened already.

[naholyr]

Because it's not portable, and especially because CLI arguments can be put
in mocha.opts which means any way the developer runs the test (if he
wants to run mocha instead of npm test) the environment is set properly.

On 6 September 2014 00:20, Travis Jeffery notifications@github.com wrote:

nah. why add mocha test --env SOME_VAR=whatever when there's SOME_VAR=whatever
mocha ?

—
Reply to this email directly or view it on GitHub
#185 (comment).

Nicolas Chambrier, aka naholyr

Blog : http://naholyr.fr
Formateur Clever Institut :
http://clever-institut.com/formateur/nicolas-chambrier

[boneskull]

No, Mocha doesn't need this in its core. There are plenty of other ways to get this done.

Some options include, but are not limited to:

1. Use a Makefile or some other task runner. Highly recommended!
2. Use npm itself and set environment variables via config and/or scripts
3. ENV_VAR=foo mocha (seriously, if you are tired of writing this, see 1.)
4. dumb plugin

The root cause of this, of course, is that your application needs an environment variable in the first place. Could it do without? What about a config or run control file? What about multiple environments? Does your app need to run in multiple environments? Can you standardize it, and spin up Vagrant machines instead?

What about your team? Is it Mocha's problem that your team doesn't know to set the proper environment variables? Is there any reason this hasn't been automated?

[felixfbecker]

As far as I know NODE_ENV=test mocha doesn't work on Windows, neither does make.

[felixfbecker]

It would be nice to have a simple --env option so you can write tests that don't depend on a specific platform.

[tswaters]

@felixfbecker - for windows, set NODE_ENV=test && mocha

I've since discovered cross-env... cross-env NODE_ENV=test mocha

[felixfbecker]

Sure but then the same command will not work on *nix systems, if you want to put it in your npm test script

[naholyr]

@felixfbecker @tswaters have you checked env-test?

[felixfbecker]

That only works for NODE_ENV though and relying on values of NODE_ENV is bad practice. See http://12factor.net/config

[halkeye]

I know this is super super old, but cross-env (https://www.npmjs.com/package/cross-env) takes care of the windows issue.

[boneskull]

@halkeye Good tip, thanks.

[tombh]

I am one of those people that always runs raw mocha because I like to --grep single tests. To me this is a fundamental aspect of Test Driven Development, which in turn is a fundamental approach to software development. The suggestions to use make or npm (which do not pass on the --grep arg) betray a lack of awareness or indeed interest in a TDD approach. Which is somewhat ironic, given this is all about a prominent testing tool.

[halkeye]

npm run test -- --grep whatever will work fine

Also you can use https://www.npmjs.com/package/env-test and add requires env-test to your mocha.opts too

There's lots of options out there.

[tombh]

But should someone that doesn't know that npm run test -- --grep whatever works, then goes straight to mocha, be penalised?

Mocha itself should be the one championing idempotency. The env-test plugin is the only real solution here.

[jasonk]

Since this still seems to get a lot of traffic I thought I would throw out a relatively simply solution for people like me who wish there was a --env flag. What I've been doing is add a test/mocha.env.js file in the repo, and then add --require test/mocha.env.js to mocha.opts:

// mocha.opts
--require babel-register
--require test/mocha.env.js
--timeout 60000

// mocha.env.js
process.env.NODE_ENV = 'test';

[demisx]

Per @jasonk, the same approach works in TypeScript:

// In mocha.opts
--require test/mocha.env
...

// In mocha.env.ts
process.env.NODE_ENV = 'test'

[AlexanderTserkovniy]

Guys, cannot get what do you mean by "There are plenty of other ways to get this done" #185 (comment).
I have simple requirement my CI&CD should be able to change env variables for TEST/STAGE/PROD, how it would do it? Change .env file on flight? Or how?

[AlexanderTserkovniy]

Okay, I had to do this way (within package.json script section):
"test": "HEADLESS=$HEADLESS URL=$URL mocha -A --recursive tests -t 10000"
So it means that it will pass URL and HEADLESS params to mocha.
Examples of use:
HEADLESS=false URL=http://example.com npm run test

[krzkaczor]

Another idea: if you use mocha's config JavaScript file you can just put it there:
.mocharc.js:

process.env.NODE_ENV = 'test';

module.exports = {
  require: 'ts-node/register/transpile-only',
  extension: ['ts'],
  watchExtensions: ['ts'],
  spec: ['test/**/*.test.ts'],
}

[shalior]

since node 20.6.0: use "node-option" to natively load an env file.
.mocharc.json:

{
	"ui": "bdd",
	"node-option": ["import=tsx", "env-file=.env.test"],
}