When using #vue/cli-plugin-unit-jest, I am receiving coverage reports each time I run my unit tests, regardless of whether I have the --coverage flag in the execution line or not. I do not want to receive coverage reports on all of my untested files. When searching for an answer online, there are numerous questions about how to turn that feature on, not turn it off. I can't find it in the documentation either.
How do you disable the Coverage on Untested Files feature in Jest?
Disabling coverage similar to enabling it, just prefix the pattern with an ! like so:
{
"collectCoverageFrom": [
"**/*.{js,jsx}",
"!**/node_modules/**",
"!**/folder-with-untested-files/**"
]
}
Or disable coverage all together with "collectCoverage": false.
If that does not work, then you have this params overridden somewhere in your code.
"collectCoverage": false
in jest.config.js
You can also suppress coverage from the command line. The package I'm working with provides a test script, and I was able to pass the collectCoverage option in as a flag. The relative path here works because my test runner is called by npm and that should set the working directory to the root of my project:
npm run test -- path/to/your.spec.js --collectCoverage=false
And the other way around, you can specific a single file to collect coverage from. It'll override any broad-ranging glob you may have already defined in your project's test config files. One reminder, you collect coverage from your source file, not your spec file. And one other reminder, you can list pretty much any file you want in that coverage option, so make sure you get it right:
npm run test -- path/to/your.spec.js --collectCoverageFrom=path/to/your/source/file.js
Package.json
testw": "jest --watch --collectCoverage=false"
watches the test files for change
npm command
npm run testw Yourfilename.js
"collectCoverage": false
in package.json, will disable coverage, collection, As mentioned by #Herman you can also put ! before file pattern in value of property collectCoverageFrom in package.json
In my case, in package.json I have this statement collectCoverage:false and still I was getting errors. Then I realized I also have collectCoverageFrom line and I removed it since I did not need it. After removing the below line it worked as a charm.
"collectCoverageFrom": [
...,
...
]
Related
I want to write a unit test with Jest, with jest-dom as a mock DOM--without having to transpile. I was hoping all I had to do was import the jest-dom package with a CommonJS import. But when I do that, then run my tests (with npm test), it still fails with:
ReferenceError: document is not defined (full output here)
Any ideas how to resolve this? My test file is below.
Thanks.
My Code
myApp.test.js
require("#testing-library/jest-dom");
document.createElement("div");
After some trial and error, I got it working. Here were the edits I made:
myApp.test.js (test file)
require("#testing-library/jest-dom/extend-expect");
I saw there in this post.
package.json Add the following to top level:
"jest": {
"testEnvironment": "jest-environment-jsdom"
},
I did that b/c this doc page said I should edit my Jest testEnvironment to jest-environment-jsdom. I don't know why that string is used as the value, instead of the name of the package (test-dom). But this is what's working for me.
This doc page shows how to edit my Jest testEnvironment.
I run Cypress from the command line as:
npx cypress open --env team=XXXX --config-file my_file.json
where my_file.json is my config file and contains:
env: {
"team": ""
}
I know that when I pass a value via CLI with no space in it the Cypress runner will show that value in the configuration tab. How do I pass a value such as to team like:
--env team=XXXX XXXX
I have tried using "" and '' around the argument already and they have not worked. Thank you.
From the documentation, it says "Pass several variables using commas and no spaces". So, off the bat, it sounds like what you're trying to do isn't possible. However, it may be worth a shot to try a different method. In particular, from this screenshot from the link I provided,
you can see that the last approach passes a JSON object. Perhaps, if for some reason Cypress parses this JSON object differently, you can try
cypress run --env team='{"key": "XXXX XXXX"}'
Alternatively, you could also have multiple Cypress configuration files, each with the relevant team value. However, if you have multiple team values, this simple approach doesn't scale particularly well.
I'm going to leave this comment here, in case someone else is looking for a solution.
this is what I did, and it worked for me.
in the terminal i'm doing:
npm run chat_true -- --env type="dev test"
note the "--" before --env
that's the only way I found to overwrite my env value, set in the package.json file like:
"chat_true": "cypress open --env type=live",
I don't need a space in the middle of the value, so I'm not using a quote surrounding the value, but I just tried it and it worked.
I'm three months late :D
Normally when pointing node to a folder, if there is an index.js file there, we don't need to specify it.
I installed an NPM dependency that I am working on, npm install --save-dev suman.
Suman has an index.js file at the root of its NPM project.
In my NPM scripts for a project that depends on suman, I have this:
"scripts": {
"test": "node node_modules/suman/index.js --rnr test"
}
The above works!
But this doesn't work:
"scripts": {
"test": "node node_modules/suman --rnr test"
}
Why is this?
Perhaps the answer is obvious - the require function in node is capable of such behavior, but node itself is not.
Since the library has a bin in its package.json, you don't need to explicitly provide the path to it. Just run node suman --rnr test and npm will take care of using the correct file.
When you install a dependency with a binary in your node project, npm creates a symlink to that file in ./node_modules/.bin and uses those when running npm scripts.
You need to add the correct path:
"scripts": {
"test": "node ./node_modules/suman --rnr test"
}
Notice the ./
Update:
After thinking about this a bit more, It may not be this easy. But take a look at this link: https://docs.npmjs.com/misc/scripts - #elssar seems to be on the right track.
Sorry that I can't include my thoughts simply as a comment rather than as an answer but I don't yet have enough reputation points to comment. However, perhaps the following is relevant:
If, in your problem, the node command finds the appropriate index.js the same way as is shown in the node documentation for modules, then the documented look-up routine will find a different index.js before finding the one that (I think) you want. Specifically, before trying node_modules/suman/index.js (which is the one you want), node will look to see if the "main" field in node_modules/suman/package.json exists. In suman, it does, and it references lib/index.js (i.e. node_modules/suman/lib/index.js) which is different than the one you want. Is that relevant?
UPDATE: Just to clarify my answer with more generic language...
Your original question is a valid one because, in the absence of any other complications, if dir/index.js exists, then both of the following
node dir/index.js ...
node dir ...
should refer to the same (default) file, i.e. dir/index.js. Thus it is reasonable to be confused when those two commands give different results. The explanation is that there IS a complication: the dir/package.json file effectively redirects node dir ... to use a non-default file. This is because the "main" property refers to dir/some/other/file.js. The rules of precedence specify that, if only a directory name is used, this other file will be used before the default. Thus, you are forced to continue to use the longer and more explicit "working" command from your question.
I have a +10K lines Backbone Marionette app and we are running tests and coverage through Karma.
I would like to include all the sources so that we can have a better idea of what it is not covered by our tests.
I have been passing the includeAllSources option in the karma configuration but I still don't see karma showing the results for all files (the report only show +3K lines cover, more or less the amount of lines that we know we have test for).
Am I doing something wrong? Is there another way to include all sources?
There use to be a Karma plugin that was able to handle this but the plugin is not longer working (modified to make it run, but the results are still the same).
Is there are way to pass the --include-all-sources option to Istanbul while running it from Karma?
Try this plugin: https://github.com/kopach/karma-sabarivka-reporter. It includes files specified by pattern to coverage statistic. So, you can be sure, that you have all your source files under coverage statistic control.
Install npm install --save-dev karma-sabarivka-reporter
And update karma.conf.js similar to this:
reporters: [
// ...
'sabarivka'
// 'coverage-istanbul' or 'coverage' (reporters order is important for 'coverage' reporter)
// ...
],
coverageReporter: {
include: [
// Specify include pattern(s) first
'src/**/*.(ts|js)',
// Then specify "do not touch" patterns (note `!` sign on the beginning of each statement)
'!src/main.(ts|js)',
'!src/**/*.spec.(ts|js)',
'!src/**/*.module.(ts|js)',
'!src/**/environment*.(ts|js)'
]
},
This github issue seems to be addressing your issue and this pull request seems to fix it in version 0.5.2 of the karma-coverage plugin.
I hope you're using an earlier version and just upgrading solves your problem!
You just need to add includeAllSources: true to your coverageReporter, the Reporter Options.
Like this:
coverageReporter: {
includeAllSources: true
...
}
I'm completely new to sails, node and js in general so I might be missing something obvious.
I'm using sails 0.10.5 and node 0.10.33.
In the sails.js documentation there's a page about tests http://sailsjs.org/#/documentation/concepts/Testing, but it doesn't tell me how to actually run them.
I've set up the directories according to that documentation, added a test called test/unit/controllers/RoomController.test.js and now I'd like it to run.
There's no 'sails test' command or anything similar. I also didn't find any signs on how to add a task so tests are always run before a 'sails lift'.
UPDATE-2: After struggling a lil bit with how much it takes to run unit test this way, i decided to create a module to load the models and turn them into globals just as sails does, but without taking so much. Even when you strip out every hook, but the orm-loader depending on the machine, it can easily take a couple seconds WITHOUT ANY TESTS!, and as you add models it gets slower, so i created this module called waterline-loader so you can load just the basics (Its about 10x faster), the module is not stable and needs test, but you are welcome to use it or modify it to suit your needs, or help me out to improve it here -> https://github.com/Zaggen/waterline-loader
UPDATE-1:
I've added the info related to running your tests with mocha to the docs under Running tests section.
Just to expand on what others have said (specially what Alberto Souza said).
You need two steps in order to make mocha work with sails as you want. First, as stated in the sails.js Docs you need to lift the server before running your test, and to do that, you create a file called bootstrap.test.js (It can be called anything you like) in the root path (optional) of your tests (test/bootstrap.test.js) that will be called first by mocha, and then it'll call your test files.
var Sails = require('sails'),
sails;
before(function(done) {
Sails.lift({
// configuration for testing purposes
}, function(err, server) {
sails = server;
if (err) return done(err);
// here you can load fixtures, etc.
done(err, sails);
});
});
after(function(done) {
// here you can clear fixtures, etc.
sails.lower(done);
});
Now in your package.json, on the scripts key, add this line(Ignore the comments)
// package.json ....
scripts": {
// Some config
"test": "mocha test/bootstrap.test.js test/**/*.test.js"
},
// More config
This will load the bootstrap.test.js file, lift your sails server, and then runs all your test that use the format 'testname.test.js', you can change it to '.spec.js' if you prefer.
Now you can use npm test to run your test.
Note that you could do the same thing without modifying your package.json, and typying mocha test/bootstrap.test.js test/**/*.test.js in your command line
PST: For a more detailed configuration of the bootstrap.test.js check Alberto Souza answer or directly check this file in hist github repo
See my test structure in we.js: https://github.com/wejs/we-example/tree/master/test
You can copy and paste in you sails.js app and remove we.js plugin feature in bootstrap.js
And change you package.json to use set correct mocha command in npm test: https://github.com/wejs/we-example/blob/master/package.json#L10
-- edit --
I created a simple sails.js 0.10.x test example, see in: https://github.com/albertosouza/sails-test-example
Given that they don't give special instructions and that they use Mocha, I'd expect that running mocha from the command line while you are in the parent directory of test would work.
Sails uses mocha as a default testing framework.
But Sails do not handle test execution by itself.
So you have to run it manually using mocha command.
But there is an article how to make all Sails stuff included into tests.
http://sailsjs.org/#/documentation/concepts/Testing