I've tried to look at the source code but I am a little confused. Does the Jest changedSince option also test related files?
Yes, to be more specific it's doing an inverse resolve of dependents.
When it comes to actually reporting coverage, it will run tests as mentioned, but it will only report the coverage of the changed file(s).
Related
I'm experiencing 2 issues with Jest test coverage:
1- Jest reports 100% (Stmts, Branch, Func, and Lines) coverage for modules with no tests at all but required by tested modules
2- Jest reports 100% Branch coverage for modules with no tests nor required by tested modules
In the image:
sum is a tested module
toNum is not tested but required by sum
sub is neither tested nor required by tested modules
I've create a repo that reproduces the issue:
https://github.com/hossamnasser938/Reproduce-Jest-Coverage-Issue
Here is my package.json:
Here is my folder structure:
How do I remove the entry for sub.js from the coverage report? I really appreciate your help.
1- Jest reports 100% (Stmts, Branch, Func, and Lines) coverage for modules with no tests at all but required by tested modules
This is expected behavior when you configure Jest to collect coverage. The required modules are still executed by your test, despite them not having a test of their own. The documentation for collectCoverage states
this retrofits all executed files with coverage collection statements
Your test is executing all of the code from the required module, so the module is covered completely, 100% by your test code. Even though the module is executed by another test, you should still write a separate test for the required module to ensure it works in isolation as a unit.
2- Jest reports 100% Branch coverage for modules with no tests nor required by tested modules
Again this is expected behavior given your configuration value for collectCoverageFrom which includes sub.js, and your implementation of sub which has no branching, so Branch statements would be 100% executed (because there are none).
If you want Jest to stop reporting on sub.js then you have a couple of options:
Remove the configuration for collectCoverageFrom entirely, and
that will remove the entry for sub.js from the coverage report
table.
Modify your value for collectCoverageFrom to specifically
ignore sub.js:
collectCoverageFrom: ['src/**/*.js', '!src/**/sub.js']
Personally, I would leave everything as-is to serve as a reminder that sub.js still needs to be tested with adequate coverage.
I've recently started getting into unit testing for my Node projects with the help of Mocha. Things are going great so far and I've found that my code has improved significantly now that I'm thinking about all the angles to cover in my tests.
Now, I'd like to share my experience with the rest of my team and get them going with their own tests. Part of the information I'd like to share is how much of my code is actually covered.
Below is a sample of my application structure which I've separated into different components, or modules. In order to promote reuse I'm trying to keep all dependencies to a minimum and isolated to the component folder. This includes keeping tests isolated as well instead of the default test/ folder in the project root.
| app/
| - component/
| -- index.js
| -- test/
| ---- index.js
Currently my package.json looks like this. I'm toying around with Istanbul, but I'm in no way tied to it. I have also tried using Blanket with similar levels of success.
{
"scripts": {
"test": "clear && mocha app/ app/**/test/*.js",
"test-cov": "clear && istanbul cover npm test"
}
If I run my test-cov command as it is, I get the following error from Istanbul (which is not helpful):
No coverage information was collected, exit without writing coverage information
So my question would be this: Given my current application structure and environment, how can I correctly report on my code coverage using Istanbul (or another tool)?
TL;DR
How can I report on my code coverage using Node, Mocha, and my current application structure?
EDIT
To be clear, Mocha is running tests correctly in this current state. Getting the code coverage report is what I'm struggling with getting to work.
EDIT 2
I received a notification that another question may have answered my question already. It only suggested installing Istanbul and running the cover command, which I have done already. Another suggestion recommends running the test commands with _mocha, which from some research I have done is to prevent Istanbul from swallowing the flags meant for Mocha and is not necessary in newer versions of Mocha.
You should try running your test like this :
istanbul cover _mocha test/**/*.js
You need an .istanbul.yml file. I don't see any reference to it - hard to say without knowing the contents of it.
I don't think there's quite enough information to solve this in the question. I'll update this answer if you update the question, especially before the bounty expires, eh?
This is how i get code coverage on all my js projects (looks like the one from Sachacr) :
istanbul cover _mocha -- -R spec --recursive test
I have a multimodule maven project with modules such as: moduleA, moduleB, moduleC. Then I have an entirely separate moduleTest that has integration tests in it run by the failsafe plugin.
I want to have a report generated by cobertura(or any other maven plugin) that can tell me which lines in all of moduleA, B and C are covered by my integration tests.
I don't think http://jira.codehaus.org/browse/MCOBERTURA-65 helps me. Is there an easy way to achieve this?
One of possible solutions is to use Emma. You shall setup code instrumentation in your source code modules by using instrument goal:
http://mojo.codehaus.org/emma-maven-plugin/instrument-mojo.html
After successful compilation and instrumentation, tests execution will generate coverage data. Then You can execute emma standalone tool to generate report based on it:
java emma report -r txt,xml,html -in coverageA.em,coverageB.em,coverageC.em,coverage.ec -sp srcA/,srcB,srcC
coverage*.em shall be replaced with proper paths to generated by Emma metadata in source code modules, coverage.ec is path to coverage file generated in test module, src* directories shall be replaced with paths to source code directories. Here is detailed documentation:
http://emma.sourceforge.net/reference/ch02s04s03.html
You can do it also with jacoco (also in a quite tricky way) but due too low reputation I cannot put more than 2 links. So like it like it! :)
I'm new to Node.js.
module.exports = process.env.EXPRESS_COV
? require("./lib-cov/express")
: require("./lib/express");
I know EXPRESS_COV returns a Boolean value, but what is the difference between lib-cov/express and lib/express?
process.env.EXPRESS_COV would be true when you're running tests and want to see the code coverage of those tests (i.e. how many lines of your codebase are actually executed when the tests are run). Mocha, the test framework used for express, achieves this through the use of jscoverage.
JSCoverage parses through your source code and adds a bunch of lines that look like this:
$_jscoverage[filename][line]++;
Naturally, that's rather confusing to have in one's source code, not to mention adding a lot of bulk. So we'd never want JSCoverage processed files in our codebase. Fortunately, JSCoverage places the modified files in a different directory. In this case, ./lib-cov/ instead of ./lib/. That way, we can see how effective our tests are and not clutter up our code.
For details on how this whole rigamarole runs, see TJ Holowaychuk's article.
If you want to avoid all of this, you can use Istanbul instead, as it's much simpler and doesn't require exceptions in index.js
After successfully optimizing and building the modules using r.js library, you would find the file build.txt with the summary of all the modules and its dependencies.
I don't want this build.txt file to reach the production server.
Apart from manually deleting the build.txt, is there any way to suppress or remove this file?
Manual deletion is not the answer that I am looking for as you might forget to delete it sometimes.
As I understood the source code, there is no way to prevent the creation of the build.txt.
This feature has been requested: https://github.com/jrburke/r.js/pull/722/files
To use it, you would add the following option to your build.js file:
noBuildTxt: true
As Louis points out, it hasn't actually been added :/
If you want, you can do what I did and restructure your application so you don't need a modules property, add the noBuildTxt option and then pretend it works. (Removing the modules property was what got rid of the module definitions, not the noBuildTxt)