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
Related
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).
If in my package.json I define a yarn script test that only calls nightwatch command; It seems as it is that it'll run both the scenarios that are found in the features folder as well as any test that is not necessarily a test made with Cucumber (plain nightwatch tests under the tests/ folder).
Is there a way for me to distinguish the execution of only the "cucumber+nightwatch" tests from the plain nightwatch ones, so I filter and only run from one of the two sets?
The author of nightwatch-cucumber suggested this approach via e-mail:
use an environment variable in nightwatch configuration (JS based).
This environment variable can decide the source of the tests.
One note: this package will be deprecated if nightwatch 1.x will come
out. So I suggest not to invest to much time with it instead use the
new nightwatch-api package.
A quick workaround to filter out plain nightwatch tests from the cucumber+nightwatch ones was to edit the src_folders in the nightwatch.json file to an empty array, like this:
{
"src_folders" : [],
...
}
I used to put all my tests together inside of __test__ directory. But I decided to put each test files into each component's directory with different name convention.
Old Structure:
src/
__test__/
example.test.js
example2.test.js
New Structure:
src/
components/
example/
example-controller.js
example-model.js
example-route.js
example-test.js
As naming and location of a directory changed, I updated all import statement and namings for according files. I was using default feature of Jest but since I changed test file name to example-test from example.test I also updated package.json
"jest": {
"testRegex": "./src/components/*/.*.-test.js$"
},
Problem is when I run the project, npm run it throws
beforeAll((0, _asyncToGenerator3.default)( /#PURE/_regenerator2.default.mark(function _callee() {
ReferenceError: beforeAll is not defined
any idea why it is happening?
Try regextester with your file-paths before getting frustrated. Also, look at some popular existing javascript projects using jest and check their jest configurations to see how the community is settling on project structure. It may seem simple to follow others, but most software engineers don't work alone, and usually agree on good practices.
Consider coming back to this project in a year; You are changing the default behavior of a simple process that works beautifully out of the box. Someone may hate you later after a git blame.
If all you want to do is check all -test.js files, slowly modify the default config until you match the file paths you want.
(/__tests__/.*|(\\.|/)(test|spec))\\.[jt]sx?$
Should probably (for you) be:
(.*/src/.*(-test).jsx?)
I have a TypeScript project that compiles down to a single JS file in /dist.
I have Jasmine tests, also written in TypeScript, that reference the various classes they test with references like:
/// <reference path="../../../src/script/classUnderTest.ts" />
When I compile the tests the TypeScript compiler pulls in all the referenced classes and I get a single JS file containing the test code and the code under test.
This actually works fine for just running the tests, but now I'd like code coverage too. From what I can tell, to get Istanbul to work I need to have the code under test separate from the test code. Also it would be nice to be testing exactly the JS file that will be live.
So, how can I get the type safety and autocomplete benefits of "/// reference" whilst using my compiled JS file when the tests are actually run?
(Or am I barking up the wrong tree entirely?)
Note, I am building this on a Mac, so from what I've read Chutzpah is not currently an option. I'm also currently using only npm scripts to do builds. I'd prefer to not bring in grunt or gulp unless it's absolutely necessary.
So, how can I get the type safety and autocomplete benefits of "/// reference" whilst using my compiled JS file when the tests are actually run?
Don't using TypeScript's --outFile option (few other reasons). Instead use modules e.g. --module commonsjs and a module loader e.g. webpack.
More
Browser quickstart : https://basarat.gitbooks.io/typescript/content/docs/quick/browser.html
Modules:
https://basarat.gitbooks.io/typescript/content/docs/project/modules.html
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