I have two types of test suites - normal and coverage.
At present, I am allowing one of them via npm test and one of them via npm start:
"scripts": {
"test": "node scripts/run-truffle-tests.js",
"start": "node scripts/run-sol-coverage.js"
}
I have a feeling that npm start was not originally designated for this purpose.
Is there a better way to implement this?
I was thinking of passing an argument to npm test, but I'm not sure that npm would pass it on to the script which it is set to invoke.
Add more scripts.
I usually have the tests for actual, full, single run unit tests to work with CI and other scripts for variations:
{
"scripts": {
"test": "node scripts/run-truffle-tests.js && npm run test:coverage",
"test:continuous": "karma start some.config --run-continuous",
"test:coverage": "node scripts/run-sol-coverage.js"
"start": "node index.js"
}
}
You can also chain commands with && which will cause the script to be run in sequence and the "total" error code will propagate. In other words, using the test I have above, will run both the unit test and the coverage test. If either of them return a non-zero exit code, npm will consider the whole test process to have failed.
Bear in mind that for custom scripts not named exactly start and test as well as the other designated scripts found in the docs here: npm#scripts, must be run with
npm run scriptname
instead of just
npm scriptname
So in my above example, you would test coverage with:
npm run test:coverage
Also, the : is just a convention. As far as I know it's not special.
Additionally, you can
pass [argument] on to the script which it is set to invoke
Whenever use use npm test, what is basically happening is that npm runs whatever String value is set in the package.json's scripts.test as a process, as though you had typed that String into the shell yourself. It then looks at the return code and if it's 0, it reports as everything being ok; if it's non-zero, it prints an error.
Related
I want to ask the community if they have ever seen this issue before.
when running a simple "npm t" command, I am getting the following error
GTaylor#slayer MINGW64 /d/slayer/packages/components (feature/HUBBLU-54)
$ npm t
> fl-components#1.0.0 test D:\slayer\packages\components
> jest --config=jest.json
s" --config=jest.json was unexpected at this time.
D:\slayer\packages\components>)s" --config=jest.json
npm ERR! Test failed. See above for more details.
the script is
"scripts": {
"build": "tsc -d",
"test": "jest --config=jest.json"
}
If I run the command directly this work. I also have other project (in another solution) that works.
This is a Lerna project with multiple packages and they all suffer from the same issue. Note that this was working on one point.
I have no idea where the "s" is coming from. It feels like it trying to run a following command .. but where the hell is the "s" and new lines coming from????
"jest --config=jest.json\n\ns -config=jest.json"
please help before I go mad.... :)
While creating package.json from command line using npm init for creating a module in Node.js, there is a test command field that I don't know about. There's no mention of it in the docs too on executing npm help json also in the CLI.
Please explain what it is about.
The test command is the command that is run whenever you call npm test.
This is important when integrating with continuous integration/continuous deployment tools (such as jenkins, codeship, teamcity).
Example:
- say you deploy a project to AWS or some other cloud hosting provider,
- you can set up your infrastructure to automatically run npm test.
- If there are problems within those tests, your ci/cd will automatically rollback before deploying.
To execute tests
You can use karma, jest, or selenium/nightmare/phantomjs or about any other test scripting library/framework that allows you to write and execute tests and then set the required command in scripts.test and finally run it from npm test.
Assuming you mean scripts.test:
"scripts" : {
"test" : "echo \"Error: no test specified\" && exit 1"
}
This field contains the program(/command line) that should run when you call npm test. Typically, that program is a test-runner like mocha, ava, jest, ...
The default value is a placeholder that prints an error message (try running npm test in the same directory as your package.json).
I have an npm script that looks like:
"scripts": {
"example": "webpack-dev-server --content-base examples/embeddable/"
},
I'd like to form the --content-base argument dynamically based on whatever's passed when calling the npm script, like:
npm run example -- embeddable
I know the -- syntax works for making args available to process.argv, but I'm not calling a Node script here so I'm not sure how to access them when forming the command. Does anyone else know of a good, cross-platform way to do this? (Must work on Windows 7, i.e. without bash capabilities.)
This should work ($1 is replaced by whatever you add as first parameter):
"scripts": {
"example": "webpack-dev-server --content-base examples/${1}/"
},
Run it like this:
npm run example -- embeddable
Currently, I have two folders: __tests__ for unit (fast) tests and __integration__ for slow tests.
Then, in package.json:
{
"scripts": {
"test": "jest",
"test:integration": "jest -c '{}'",
...
},
"jest": {
"testPathIgnorePatterns": ["/node_modules/", "__integration__"]
}
}
So, when I want to do TDD, I'm running just npm test and when I want to test the entire project, npm run test:integration.
As Jest is offered as a "no configuration" test framework, I was thinking if there's a better (or proper) way to configure this.
Thank you.
Quoting from this post.
You can try name files like:
index.unit.test.js and api.int.test.js
And with Jest’s pattern matching feature, it makes it simple to run
them separately as well. For unit testing run jest unit and for
integration testing run jest int.
File structure/location you can define based on your preferences as the pattern matching based on the file name is how jest knows what to run.
Also see jest cli documentation about npm scripts:
If you run Jest via npm test, you can still use the command line
arguments by inserting a -- between npm test and the Jest arguments
Have you tried jest --watch for TDD? It runs only files related to your git changes, runs errors first and heavily utilise cache for speed.
Other than that, jest -c accepts a path, not a string. You should be good with jest -c jest-integration-config.json, provided that jest-integration-config.json sits in your project's root.
I am using Mocha for testing my NodeJS application. I am not able to figure out how to use its code coverage feature. I tried googling it but did not find any proper tutorial. Please help.
You need an additional library for code coverage, and you are going to be blown away by how powerful and easy istanbul is. Try the following, after you get your mocha tests to pass:
npm install nyc
Now, simply place the command nyc in front of your existing test command, for example:
{
"scripts": {
"test": "nyc mocha"
}
}
Now (2023) the preferred way to use istanbul is via its "state of the art command line interface" nyc.
Setup
First, install it in your project with
npm i nyc --save-dev
Then, if you have a npm based project, just change the test script inside the scripts object of your package.json file to execute code coverage of your mocha tests:
{
"scripts": {
"test": "nyc --reporter=text mocha"
}
}
Run
Now run your tests
npm test
and you will see a table like this in your console, just after your tests output:
Customization
Html report
Just use
nyc --reporter=html
instead of text. Now it will produce a report inside ./coverage/index.html.
Report formats
Istanbul supports a wide range of report formats. Just look at its reports library to find the most useful for you.
Just add a --reporter=REPORTER_NAME option for each format you want.
For example, with
nyc --reporter=html --reporter=text
you will have both the console and the html report.
Don't run coverage with npm test
Just add another script in your package.json and leave the test script with only your test runner (e.g. mocha):
{
"scripts": {
"test": "mocha",
"test-with-coverage": "nyc --reporter=text mocha"
}
}
Now run this custom script
npm run test-with-coverage
to run tests with code coverage.
Force test failing if code coverage is low
Fail if the total code coverage is below 90%:
nyc --check-coverage --lines 90
Fail if the code coverage of at least one file is below 90%:
nyc --check-coverage --lines 90 --per-file
Blanket.js works perfect too.
npm install --save-dev blanket
in front of your test/tests.js
require('blanket')({
pattern: function (filename) {
return !/node_modules/.test(filename);
}
});
run mocha -R html-cov > coverage.html
The accepted answer (nyc) does not work if you are using ESM modules.
C8 appears to be the best solution now, which leverages built-in NodeJS capabilities and utilizes istanbul (like nyc, and shares the same config files).
npm install -g c8
c8 mocha
It will use .nycrc for configuration. A sample configuration I'm using is:
{
"all": true,
"exclude": ["test"],
"output": "reports",
"reporter" : [
"html",
"text"
]
}
(Note: I was pointed to c8 by an answer to another question https://stackoverflow.com/a/69846825/1949430)