This is a plugin for gulp which runs Mocha tests in a
separate process from the gulp
process. Each time tests are run a new child
process is created meaning the test environment always starts cleanly (i.e.,
globals are reset as are non-enumerable properties defined on native
prototypes via Object.defineProperty
. This also means that if your tests
crash the node process (e.g., process.exit(-1)
.) then an error
event is
emitted rather than your whole gulp
process crashing (good for watching). It
is simple enough to make gulp crash when necessary (e.g., for continuous
integration) by throwing the error as outlined below.
Usage is according to this API:
stream.pipe(mocha({
// options
}))
This plugin defines mocha
~1
as a peerDependency
meaning that you can
define a dependency on any version of mocha
in your package.json
and that
version will be used to run tests. If you don't specify a mocha
in your
package.json, then the latest 1.x
version will automatically be installed.
There are two special options: bin
and env
. You can set bin
to be a path
to a mocha
executable to use instead of the one this plugin looks for by
default. This is useful if you want to use a fork of mocha
which goes by a
different name. You can pass an object as the env
option to set the
environment variables that the child process will have access to (key-value
pairs, see [child_process::spawn][spawn]).
All other options are properly prefixed with either -
or --
and passed to
the mocha
executable. Any arguments which do not take a value (e.g., c
,
colors
, or debug
) should just have a value of true
. Any arguments which
have dashes in the name can be specified by using camelCase (i.e., debugBrk
for --debug-brk
, inlineDiffs
for --inline-diffs
, etc) so you don't have
to use strings for the argument names. See the following example usage:
var gulp = require('gulp'),
mocha = require('gulp-spawn-mocha');
gulp.task('test', function () {
return test().on('error', function (e) {
throw e;
});
});
gulp.task('default', function () {
gulp.watch('{lib,test}/*', test);
test();
});
function test() {
return gulp.src(['test/*.test.js'], {read: false}).pipe(mocha({
r: 'test/setup.js',
R: 'spec',
c: true,
inlineDiffs: true,
debug: true
})).on('error', console.warn.bind(console));
}
The test
function will run the mocha
executable telling it to require
test/setup.js
and use the spec
reporter -- if there is an error it will
output a warning to the console. See mocha -h
for additional options.
The test
task will throw an error, crashing gulp
(good for continuous
integration environments).
The default
task will watch for changes and execute tests whenever a change
is detected. It will also execute tasks immediately without waiting for a
change.
As mentioned above an object provided underneath the env
options key will
allow you to specify a custom environment. This is useful, for example, to run
your tests in a different NODE_ENV than the default. Such a gulp task would
look like:
var gulp = require('gulp'),
mocha = require('gulp-spawn-mocha');
gulp.task('test', function() {
return gulp
.src(['test/*.test.js'])
.pipe(mocha({
env: {'NODE_ENV': 'test'}
}));
});
Because of the nature of this plugin launching an external process to run
tests, the standard coverage plugins for gulp will not work with this module.
Starting in version 0.4.0
Istanbul is included as a peer dependency
in order to enable code coverage reports without having to instrument code on
disk. You can use it by passing the istanbul
option.
Set istanbul
to true
if you want to use all the default settings:
gulp.task('test', function() {
return gulp
.src(['test/*.test.js'])
.pipe(mocha({
istanbul: true
}));
});
This will launch a process equivilant to:
istanbul cover -- _mocha
The default settings of Istanbul output to a directory in the cwd
called
coverage
.
If you want to pass options to Istanbul, you can do that as well:
gulp.task('test', function() {
return gulp
.src(['test/*.test.js'])
.pipe(mocha({
istanbul: {
dir: 'path/to/custom/output/directory'
}
}));
});
This will launch a process equivilant to:
istanbul cover --dir path/to/custom/output/directory -- _mocha
This will output do a directory called path/to/custom/output/directory
.
Assuming you are using Travis for CI and Coveralls for
publishing code coverage reports it is very easy to automatically have Travis
publish to Coveralls when tests are run successfully. First make sure you
install and save the coveralls
module as a dev dependency:
npm i --save-dev coveralls
Then edit your .travis.yml
to have an after_success
command:
language: node_js
node_js:
- "0.11"
- "0.10"
after_success: ./node_modules/.bin/coveralls --verbose < coverage/lcov.info
The coveralls
module requires no additional configuration to publish to
Coveralls as long as both Travis and Coveralls are configured for the same
public repository. See node-coveralls
for more details.
The original gulp-mocha
is fine in most circumstances. If you need your
tests to run as a separate process (or a separate process is simply your
preference for the reasons specified above) or you need to use a custom
version of Mocha (e.g., a fork with bug fixes or custom functionality) then
you should use this plugin.
The MIT License
Copyright (c) 2014 Kenneth Powers
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.