Gathering detailed insights and metrics for grunt-karma
Gathering detailed insights and metrics for grunt-karma
Gathering detailed insights and metrics for grunt-karma
Gathering detailed insights and metrics for grunt-karma
grunt-karma-coveralls
An npm module for using Karma and Coveralls with Grunt
grunt-karma-sonar
Grunt plugin for integrating karma reports with sonar
grunt-cmp-karma
Grunt karma ranner for cmp components
karma-sourcemap-loader
Karma plugin that locates and loads existing javascript source map files.
npm install grunt-karma
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
468 Stars
241 Commits
116 Forks
10 Watching
16 Branches
57 Contributors
Updated on 05 Aug 2024
Minified
Minified + Gzipped
JavaScript (100%)
Cumulative downloads
Total Downloads
Last day
27.2%
17,211
Compared to previous day
Last week
5.5%
89,028
Compared to previous week
Last month
11.9%
354,106
Compared to previous month
Last year
-3%
4,111,108
Compared to previous year
1
28
Grunt plugin for Karma
This current version uses karma@^3.0.0
. For using older versions see the
old releases of grunt-karma.
From the same directory as your project's Gruntfile and package.json, install karma and grunt-karma with the following commands:
1$ npm install karma --save-dev 2$ npm install grunt-karma --save-dev
Once that's done, add this line to your project's Gruntfile:
1grunt.loadNpmTasks('grunt-karma');
Inside your Gruntfile.js
file, add a section named karma
, containing
any number of configurations for running karma. You can either put your
config in a [karma config file] or leave it all in your Gruntfile (recommended).
1karma: { 2 unit: { 3 configFile: 'karma.conf.js' 4 } 5}
1karma: { 2 unit: { 3 options: { 4 files: ['test/**/*.js'] 5 } 6 } 7}
You can override any of the config file's settings by putting them directly in the Gruntfile:
1karma: { 2 unit: { 3 configFile: 'karma.conf.js', 4 port: 9999, 5 singleRun: true, 6 browsers: ['PhantomJS'], 7 logLevel: 'ERROR' 8 } 9}
To change the logLevel
in the grunt config file instead of the karma config, use one of the following strings:
OFF
, ERROR
, WARN
, INFO
, DEBUG
The files
option can be extended "per-target" in the typical way
Grunt handles files:
1karma: { 2 options: { 3 files: ['lib/**/*.js'] 4 }, 5 unit: { 6 files: [ 7 { src: ['test/**/*.js'] } 8 ] 9 } 10}
When using the "Grunt way" of specifying files, you can also extend the file objects with the options supported by karma:
1karma: { 2 unit: { 3 files: [ 4 { src: ['test/**/*.js'], served: true }, 5 { src: ['lib/**/*.js'], served: true, included: false } 6 ] 7 } 8}
files
When using template strings in the files
option, the results will flattened. Therefore, if you include a variable that includes an array, the array will be flattened before being passed to Karma.
Example:
1meta: { 2 jsFiles: ['jquery.js','angular.js'] 3}, 4karma: { 5 options: { 6 files: ['<%= meta.jsFiles %>','angular-mocks.js','**/*-spec.js'] 7 } 8}
If you have multiple targets, it may be helpful to share common
configuration settings between them. Grunt-karma supports this by
using the options
property:
1karma: { 2 options: { 3 configFile: 'karma.conf.js', 4 port: 9999, 5 browsers: ['Chrome', 'Firefox'] 6 }, 7 continuous: { 8 singleRun: true, 9 browsers: ['PhantomJS'] 10 }, 11 dev: { 12 reporters: 'dots' 13 } 14}
In this example the continuous
and dev
targets will both use
the configFile
and port
specified in the options
. But
the continuous
target will override the browser setting to use
PhantomJS, and also run as a singleRun. The dev
target will simply
change the reporter to dots.
There are three ways to run your tests with karma:
Setting the autoWatch
option to true will instruct karma to start
a server and watch for changes to files, running tests automatically:
1karma: { 2 unit: { 3 configFile: 'karma.conf.js', 4 autoWatch: true 5 } 6}
Now run $ grunt karma
Many Grunt projects watch several types of files using grunt-contrib-watch.
Config karma like usual (without the autoWatch option), and add
background:true
:
1karma: { 2 unit: { 3 configFile: 'karma.conf.js', 4 background: true, 5 singleRun: false 6 } 7}
The background
option will tell grunt to run karma in a child process
so it doesn't block subsequent grunt tasks.
The singleRun: false
option will tell grunt to keep the karma server up
after a test run.
Config your watch
task to run the karma task with the :run
flag. For example:
1watch: { 2 //run unit tests with karma (server needs to be already running) 3 karma: { 4 files: ['app/js/**/*.js', 'test/browser/**/*.js'], 5 tasks: ['karma:unit:run'] //NOTE the :run flag 6 } 7},
In your terminal window run $ grunt karma:unit:start watch
, which starts the
karma server and the watch task. Now when grunt watch detects a change to
one of your watched files, it will run the tests specified in the unit
target using the already running karma server. This is the preferred method
for development.
Keeping a browser window & karma server running during development is
productive, but not a good solution for build processes. For that reason karma
provides a "continuous integration" mode, which will launch the specified
browser(s), run the tests, and close the browser(s). It also supports running
tests in PhantomJS, a headless webkit browser which is great for running tests as part of a build. To run tests in continous integration mode just add the singleRun
option:
1karma: { 2 unit: { 3 configFile: 'config/karma.conf.js', 4 }, 5 //continuous integration mode: run tests once in PhantomJS browser. 6 continuous: { 7 configFile: 'config/karma.conf.js', 8 singleRun: true, 9 browsers: ['PhantomJS'] 10 }, 11}
The build would then run grunt karma:continuous
to start PhantomJS,
run tests, and close PhantomJS.
You can pass arbitrary client.args
through the commandline like this:
1$ grunt karma:dev watch --grep=mypattern
MIT License
The latest stable version of the package.
Stable Version
1
9.8/10
Summary
Grunt-karma vulnerable to prototype pollution
Affected Versions
<= 4.0.1
Patched Versions
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
Found 7/16 approved changesets -- score normalized to 4
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
project is not fuzzed
Details
Reason
security policy file not detected
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
86 existing vulnerabilities detected
Details
Score
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