Installations
npm install grunt-mocha-test
Releases
Unable to fetch releases
Developer
Developer Guide
Module System
Unable to determine the module system for this package.
Min. Node Version
>= 0.10.4
Typescript Support
No
Node Version
8.6.0
NPM Version
5.3.0
Statistics
362 Stars
249 Commits
61 Forks
7 Watching
9 Branches
25 Contributors
Updated on 30 Aug 2024
Languages
JavaScript (98.55%)
CoffeeScript (1.45%)
Total Downloads
Cumulative downloads
Total Downloads
18,813,449
Last day
-39.3%
8,291
Compared to previous day
Last week
3.1%
77,048
Compared to previous week
Last month
89%
274,702
Compared to previous month
Last year
-4%
1,969,596
Compared to previous year
Daily Downloads
Weekly Downloads
Monthly Downloads
Yearly Downloads
Peer Dependencies
1
grunt-mocha-test
A grunt task for running server side mocha tests
Usage
Install next to your project's Gruntfile.js with:
npm install grunt-mocha-test --save-dev
Running tests
Here is a simple example gruntfile if you just want to run tests
1module.exports = function(grunt) { 2 3 // Add the grunt-mocha-test tasks. 4 grunt.loadNpmTasks('grunt-mocha-test'); 5 6 grunt.initConfig({ 7 // Configure a mochaTest task 8 mochaTest: { 9 test: { 10 options: { 11 reporter: 'spec', 12 captureFile: 'results.txt', // Optionally capture the reporter output to a file 13 quiet: false, // Optionally suppress output to standard out (defaults to false) 14 clearRequireCache: false, // Optionally clear the require cache before running tests (defaults to false) 15 clearCacheFilter: (key) => true, // Optionally defines which files should keep in cache 16 noFail: false // Optionally set to not fail on failed tests (will still fail on other errors) 17 }, 18 src: ['test/**/*.js'] 19 } 20 } 21 }); 22 23 grunt.registerTask('default', 'mochaTest'); 24 25};
Options
The following options are specific to grunt-mocha-test
(ie. not mocha options)
captureFile
- specify a file to capture all output to (will include any output fromconsole.log
)quiet
-true
to not output anything to console (normally used with thecaptureFile
option when console output would not be human readable)clearRequireCache
-true
to clear the require cache before each test run (normally used with watch when not spawning each test run in a newnodejs
context)clearCacheFilter
-function() { return true/false }
to say which files should remain in cache. Only works withclearRequireCache
set totrue
)noFail
-true
to prevent the task failing on failed tests. Useful for CI setups where test reports are processed separately. Will still fail on other errors
The following mocha options have also been tested (others may have been added since the time of writing through changes to mocha)
- grep
- ui
- reporter
- timeout
- invert
- ignoreLeaks
- growl
- globals
- bail
- require
- slow
Specifying compilers
The Mocha --compilers
option is almost identical to the --require
option but with additional functionality for use with the Mocha --watch
mode. As the --watch
mode is not relevant for this plugin there is no need to implement a separate compilers
option and actually the require
option should be used instead.
The following example shows the use of the CoffeeScript compiler.
npm install coffee-script
1mochaTest: { 2 test: { 3 options: { 4 reporter: 'spec', 5 require: 'coffee-script/register' 6 }, 7 src: ['test/**/*.coffee'] 8 } 9}
This is an example for the Babel 6 compiler (babel must be configured separately if you want to use it for something like ES6/ES2015).
npm install babel-register
1mochaTest: { 2 test: { 3 options: { 4 reporter: 'spec', 5 require: 'babel-register' 6 }, 7 src: ['test/**/*.js'] 8 } 9}
In order to make this more user friendly, the require
option can take either a single file/function or an array of files/functions in case you have other globals you wish to require.
eg.
1mochaTest: { 2 test: { 3 options: { 4 reporter: 'spec', 5 require: [ 6 'coffee-script/register', 7 './globals.js', 8 function(){ testVar1=require('./stuff'); }, 9 function(){ testVar2='other-stuff'; } 10 ] 11 }, 12 src: ['test/**/*.coffee'] 13 } 14}
NB. File references for the require
option can only be used with Javascript files, ie. it is not possible to specify a ./globals.coffee
in the above example.
Specifying a Mocha module
grunt-mocha-test
uses npm's peerDependency
functionality and thus uses whatever version
of mocha
is installed in your project. If your project does not have mocha
installed, a compatible
version will automatically be installed when adding grunt-mocha-test
.
Generating coverage reports
Here is an example gruntfile that registers 2 test tasks, 1 to run the tests and 1 to generate a coverage report using blanket.js
to instrument the javascript on the fly.
npm install blanket
1module.exports = function(grunt) { 2 3 grunt.loadNpmTasks('grunt-mocha-test'); 4 5 grunt.initConfig({ 6 mochaTest: { 7 test: { 8 options: { 9 reporter: 'spec', 10 // Require blanket wrapper here to instrument other required 11 // files on the fly. 12 // 13 // NB. We cannot require blanket directly as it 14 // detects that we are not running mocha cli and loads differently. 15 // 16 // NNB. As mocha is 'clever' enough to only run the tests once for 17 // each file the following coverage task does not actually run any 18 // tests which is why the coverage instrumentation has to be done here 19 require: 'coverage/blanket' 20 }, 21 src: ['test/**/*.js'] 22 }, 23 coverage: { 24 options: { 25 reporter: 'html-cov', 26 // use the quiet flag to suppress the mocha console output 27 quiet: true, 28 // specify a destination file to capture the mocha 29 // output (the quiet option does not suppress this) 30 captureFile: 'coverage.html' 31 }, 32 src: ['test/**/*.js'] 33 } 34 } 35 }); 36 37 grunt.registerTask('default', 'mochaTest'); 38};
As noted above it is necessary to wrap the blanket require when calling mocha programatically so coverage/blanket.js
should look something like this.
1var path = require('path'); 2var srcDir = path.join(__dirname, '..', 'src'); 3 4require('blanket')({ 5 // Only files that match the pattern will be instrumented 6 pattern: srcDir 7});
This will preprocess all .js
files in the src
directory. Note that Blanket
just uses pattern matching so this rework of the paths prevents files in node_modules
being instrumented too. Also bear in mind using Blanket
to instrument files on the fly only works if the file is not already in the require cache (this is an odd case but if you can't figure out why a file is not instrumented and the pattern
looks ok then this may be the cause).
Failing tests if a coverage threshold is not reached
Building on the previous example, if you wish to have your tests fail if it falls below a certain coverage threshold then I advise using the travis-cov
reporter
npm install travis-cov
1module.exports = function(grunt) { 2 3 grunt.loadNpmTasks('grunt-mocha-test'); 4 5 grunt.initConfig({ 6 mochaTest: { 7 test: { 8 options: { 9 reporter: 'spec', 10 require: 'coverage/blanket' 11 }, 12 src: ['test/**/*.js'] 13 }, 14 'html-cov': { 15 options: { 16 reporter: 'html-cov', 17 quiet: true, 18 captureFile: 'coverage.html' 19 }, 20 src: ['test/**/*.js'] 21 }, 22 // The travis-cov reporter will fail the tests if the 23 // coverage falls below the threshold configured in package.json 24 'travis-cov': { 25 options: { 26 reporter: 'travis-cov' 27 }, 28 src: ['test/**/*.js'] 29 } 30 } 31 }); 32 33 grunt.registerTask('default', 'mochaTest'); 34};
Don't forget to update package.json
with options for travis-cov
, for example:
1 ... 2 3 "config": { 4 "travis-cov": { 5 // Yes, I like to set the coverage threshold to 100% ;) 6 "threshold": 100 7 } 8 }, 9 10 ...
Instrumenting source files with coverage data before running tests
In most cases it may be more useful to instrument files before running tests. This has the added advantage of creating intermediate files that will match the line numbers reported in exception reports. Here is one possible Gruntfile.js
that uses the grunt-blanket
plug in.
npm install grunt-contrib-clean
npm install grunt-contrib-copy
npm install grunt-blanket
npm install travis-cov
1module.exports = function(grunt) { 2 3 grunt.loadNpmTasks('grunt-mocha-test'); 4 grunt.loadNpmTasks('grunt-contrib-clean'); 5 grunt.loadNpmTasks('grunt-contrib-copy'); 6 grunt.loadNpmTasks('grunt-blanket'); 7 8 grunt.initConfig({ 9 clean: { 10 coverage: { 11 src: ['coverage/'] 12 } 13 }, 14 copy: { 15 coverage: { 16 src: ['test/**'], 17 dest: 'coverage/' 18 } 19 }, 20 blanket: { 21 coverage: { 22 src: ['src/'], 23 dest: 'coverage/src/' 24 } 25 }, 26 mochaTest: { 27 test: { 28 options: { 29 reporter: 'spec', 30 }, 31 src: ['/coverage/test/**/*.js'] 32 }, 33 coverage: { 34 options: { 35 reporter: 'html-cov', 36 quiet: true, 37 captureFile: 'coverage.html' 38 }, 39 src: ['/coverage/test/**/*.js'] 40 }, 41 'travis-cov': { 42 options: { 43 reporter: 'travis-cov' 44 }, 45 src: ['/coverage/test/**/*.js'] 46 } 47 } 48 }); 49 50 grunt.registerTask('default', ['clean', 'blanket', 'copy', 'mochaTest']); 51};
This will delete any previously instrumented files, copy the test
files to a coverage
folder and instrument the src
javascript files to the coverage
folder. Lastly it runs tests from the coverage
folder. It's more complicated but often easier to work with.
Running in permanent environments (like watch)
If you run grunt-mocha-test
with grunt-contrib-watch
using the spawn: false
option, you will notice that the tests only run on the first change. Subsequent changes will result in an empty report with a 0 passing
message.
This happens because mocha
loads your tests using require
resulting in them being added to the require cache. Thus once they have been loaded in a process the subsequent calls to require
hit the cache without executing the code again. To prevent this from happening, use the clearRequireCache
option (default value is false
).
Here is an example that also demonstrates how to only run changed tests:
1module.exports = function(grunt) { 2 3 grunt.loadNpmTasks('grunt-mocha-test'); 4 grunt.loadNpmTasks('grunt-contrib-watch'); 5 6 grunt.initConfig({ 7 mochaTest: { 8 test: { 9 options: { 10 reporter: 'spec', 11 clearRequireCache: true 12 }, 13 src: ['test/**/*.js'] 14 }, 15 }, 16 17 watch: { 18 js: { 19 options: { 20 spawn: false, 21 }, 22 files: '**/*.js', 23 tasks: ['default'] 24 } 25 } 26 }); 27 28 // On watch events, if the changed file is a test file then configure mochaTest to only 29 // run the tests from that file. Otherwise run all the tests 30 var defaultTestSrc = grunt.config('mochaTest.test.src'); 31 grunt.event.on('watch', function(action, filepath) { 32 grunt.config('mochaTest.test.src', defaultTestSrc); 33 if (filepath.match('test/')) { 34 grunt.config('mochaTest.test.src', filepath); 35 } 36 }); 37 38 grunt.registerTask('default', 'mochaTest'); 39};
Using node flags
There are some flags that Mocha supports that are actually Node flags, eg.
- --debug
- --harmony-generators
It is currently not possible to set these at runtime when using Mocha as a library and as such cannot be supported by grunt-mocha-test
without a major refactor (and severe impact on performance as it would involve spawning processes).
The recommended way of using these flags would be to pass them to node when starting the grunt process. The simplest way to do this would be to leverage the scripts
functionality of NPM and package.json
.
...
},
"scripts": {
"test": "node --debug --harmony-generators ./node_modules/.bin/grunt test"
}
...
The tests would then be run using
npm test
Note that this assumes that grunt-cli
has been installed locally and not globally
Contributing
In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using:
npm test
License
Copyright © 2016 Peter Halliday
Licensed under the MIT license.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
license file detected
Details
- Info: project has a license file: LICENSE-MIT:0
- Info: FSF or OSI recognized license: MIT License: LICENSE-MIT:0
Reason
Found 4/25 approved changesets -- score normalized to 1
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
- Warn: no security policy file detected
- Warn: no security file to analyze
- Warn: no security file to analyze
- Warn: no security file to analyze
Reason
project is not fuzzed
Details
- Warn: no fuzzer integrations found
Reason
branch protection not enabled on development/release branches
Details
- Warn: branch protection not enabled for branch 'master'
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
- Warn: 0 commits out of 10 are checked with a SAST tool
Reason
50 existing vulnerabilities detected
Details
- Warn: Project is vulnerable to: GHSA-9vvw-cc9w-f27h
- Warn: Project is vulnerable to: GHSA-gxpj-cx7g-858c
- Warn: Project is vulnerable to: GHSA-h6ch-v84p-w6p9
- Warn: Project is vulnerable to: GHSA-qrmc-fj45-qfc2
- Warn: Project is vulnerable to: GHSA-957j-59c2-j692
- Warn: Project is vulnerable to: GHSA-qh2h-chj9-jffq
- Warn: Project is vulnerable to: GHSA-m5pj-vjjf-4m3h
- Warn: Project is vulnerable to: GHSA-j383-35pm-c5h4
- Warn: Project is vulnerable to: GHSA-rm36-94g8-835r
- Warn: Project is vulnerable to: GHSA-q42p-pg8m-cqh6
- Warn: Project is vulnerable to: GHSA-w457-6q6x-cgp9
- Warn: Project is vulnerable to: GHSA-62gr-4qp9-h98f
- Warn: Project is vulnerable to: GHSA-f52g-6jhx-586p
- Warn: Project is vulnerable to: GHSA-2cf5-4w76-r9qv
- Warn: Project is vulnerable to: GHSA-3cqr-58rm-57f8
- Warn: Project is vulnerable to: GHSA-g9r4-xpmj-mj65
- Warn: Project is vulnerable to: GHSA-q2c6-c6pm-g3gh
- Warn: Project is vulnerable to: GHSA-765h-qjxv-5f44
- Warn: Project is vulnerable to: GHSA-f2jv-r9rf-7988
- Warn: Project is vulnerable to: GHSA-44pw-h2cw-w3vq
- Warn: Project is vulnerable to: GHSA-jp4x-w63m-7wgm
- Warn: Project is vulnerable to: GHSA-c429-5p7v-vgjp
- Warn: Project is vulnerable to: GHSA-43f8-2h32-f4cj
- Warn: Project is vulnerable to: GHSA-qqgx-2p2h-9c37
- Warn: Project is vulnerable to: GHSA-4hpf-3wq7-5rpr
- Warn: Project is vulnerable to: GHSA-f522-ffg8-j8r6
- Warn: Project is vulnerable to: GHSA-2pr6-76vf-7546
- Warn: Project is vulnerable to: GHSA-8j8c-7jfh-h6hx
- Warn: Project is vulnerable to: GHSA-896r-f27r-55mw
- Warn: Project is vulnerable to: GHSA-282f-qqgm-c34q
- Warn: Project is vulnerable to: GHSA-jf85-cpcp-j695
- Warn: Project is vulnerable to: GHSA-fvqr-27wr-82fm
- Warn: Project is vulnerable to: GHSA-4xc9-xhrj-v574
- Warn: Project is vulnerable to: GHSA-x5rq-j2xg-h7qm
- Warn: Project is vulnerable to: GHSA-29mw-wpgm-hmr9
- Warn: Project is vulnerable to: GHSA-35jh-r3h4-6jhm
- Warn: Project is vulnerable to: GHSA-p6mc-m468-83gw
- Warn: Project is vulnerable to: GHSA-f8q6-p94x-37v3
- Warn: Project is vulnerable to: GHSA-vh95-rmgr-6w4m / GHSA-xvch-5gv4-984h
- Warn: Project is vulnerable to: GHSA-hrpp-h998-j3pp
- Warn: Project is vulnerable to: GHSA-p8p7-x288-28g6
- Warn: Project is vulnerable to: GHSA-c2qf-rxjj-qqgw
- Warn: Project is vulnerable to: GHSA-4rq4-32rv-6wp6
- Warn: Project is vulnerable to: GHSA-64g7-mvw6-v9qj
- Warn: Project is vulnerable to: GHSA-2m39-62fm-q8r3
- Warn: Project is vulnerable to: GHSA-mf6x-7mm4-x2g7
- Warn: Project is vulnerable to: GHSA-72xf-g2v4-qvf3
- Warn: Project is vulnerable to: GHSA-7p7h-4mm5-852v
- Warn: Project is vulnerable to: GHSA-xc7v-wxcw-j472
- Warn: Project is vulnerable to: GHSA-v2p6-4mp7-3r9v
Score
1.9
/10
Last Scanned on 2024-11-18
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More