We Keep Coding

"istanbul ignore next" command seems to be ignored

I'm trying to use Jest to test my code. It was working quite fine until I tried to exclude a class method from the tests.
The querySelector() call is the reason why I want to skip this method from being tested ("document" is obviously null unless I run the script in the browser)
I tried this solution, which seems to be the most suggested one:
/* istanbul ignore next */
appendNewInputFields() {
const howMany = Number(document.querySelector('#items-to-add').value);
[...Array(howMany)].forEach( i => {
const newInputField = this.createNewItemInputField();
this.inputItemsContainerNode.append(newInputField);
});
}
But the test keeps failing and the line /* istanbul ignore next */ seems to be ignored.
I've also tried putting the comment between the function signature and its body (as was suggested somewhere here on SO), but no luck:
FAIL js/DOMManager.test.js
● Test suite failed to run
TypeError: Cannot read property 'value' of null
135 | appendNewInputFields() /* istanbul ignore next */ {
136 |
> 137 | const howMany = Number(document.querySelector('#items-to-add').value);
| ^
138 |
I've read around that this might be related to babel-plugin-istanbul. I've tried
npm --save-dev uninstall babel-plugin-istanbul
which in the terminal returned:
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents#2.3.2 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents#2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
removed 18 packages and audited 521 packages in 2.178s
but the folder babel-plugin-istanbul is still present in /node_modules/ inside my working folder and the test keeps failing as if nothing changed.
If I comment out the body of the function, the other test suites work perfectly. If I try to apply the ignore next command to any other part of the code, the tests pass just fine and the line is completely ignored.
If I try to manually delete the /babel-plugin-istanbul/ folder (from the /node_modules/ in my working folder), Jest stops working.
(This is the first time I installed Node.js, and I did it only because I wanted to start unit testing with Jest. I'm pointing this out because these are my first steps venturing out of the vanilla world. I don't know how to deal with Node.js nor npm, I just launched a couple commands to install it, I wrote a few tests for Jest and they all immediately worked fine. I'm not using any other framework, I'm trying to stick to vanilla JS as much as possible.)
----------------------- Edit:
I tried changing the code to this:
appendNewInputFields() {
// TODO solve the istanbul ignore issue
let howMany;
/* istanbul ignore if */
if(document != null) {
howMany = Number(document.querySelector('#items-to-add').value);
[...Array(howMany)].forEach( i => {
const newInputField = this.createNewItemInputField();
this.inputItemsContainerNode.append(newInputField);
});
console.log("added " + howMany + " input fields");
}
}
I keep getting
FAIL js/DOMManager.test.js
● Test suite failed to run
TypeError: Cannot read property 'value' of null
139 | /* istanbul ignore if */
140 | if(document != null) {
> 141 | howMany = Number(document.querySelector('#items-to-add').value);
| ^
142 |
143 | [...Array(howMany)].forEach( i => {
144 | const newInputField = this.createNewItemInputField();
I'm totally clueless at this point. Given the conditional, "document" should be null and that block entirely skipped, but it keeps failing the test.
The same code works exactly as intended when run in the browser.

So I made a few tests in a blank new folder, and it finally struck me.
Apparently I had misunderstood the purpose of /* istanbul ignore next */.
Its function is not to skip code from being executed during the tests, but rather prevent that portion of code to be taken into account when determining the amount of total code that has been tested. The code runs (if there is anything calling that function), but those lines just don't count when Jest sums up the amount of lines it tested (which is the purpose of --coverage, I guess). If an error occurs, it is thrown as it would normally be.
My problem wasn't really related to Jest nor the istanbul package. I feel pretty dumb realizing this now, but what I needed was just proper exception handling.
I implemented a few old fashioned try/catch blocks: now everything is tested smoothly and the istanbul ignore directive correctly behaves as expected (now that I know what to expect, that is): functions that are not tested and flagged to be ignored, they just don't appear in the final coverage report.
I hope this helps anybody who might stumble in my same misunderstanding.
Of course, if anybody more competent than me can confirm this interpretation or has any suggestion or further explanation, it would obviously be much appreciated.

I was with the same error with window.alert command with jest:
ReferenceError: alert is not defined
4 |
5 | /* istanbul ignore next */
> 6 | alert(helloWorld());
| ^
7 |
so I tried to use try-catch and SUCCESS!
before:
alert(helloWorld());
after:
const alerta = () => {
try {
return alert(helloWorld());
} catch (error) {
return false;
}
}
testes:
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total

This might also happen if your bundling tool (esbuild, for instance) removes comments, therefore istanbul does not see them.
If that's the case, you might want to change your bundling tool to something like terser (make sure that comments are not omitted there, too) or adjust minification options of the bundling tool you use.
This is how it would look like if you use Vite:
build: {
minify: 'terser',
terserOptions: {
format: {
comments: 'all', // or regular expression /istanbul\signore\s/
},
},
},

eslint on dynamically changing file list

I'd like to run eslint on modified files only. I've created a new run target in package.json to run eslint from command line (git diff --name-only --relative | grep -E '.*\\.(vue|js)$' | xargs eslint --ext .js,.vue). In theory, this should work fine, but there's a little transformation step happening in my project (a string replacement) when bundling the files with webpack that will throw off eslint (some non-standard markup will be expanded to JS).
What are my options and how would I go about implementing them? For instance, could I execute a particular webpack rule/loader and pipe the result to eslint? Another option I see is to include eslint into the webpack rule/loader process (instead of executing it from the command line), but how would I then filter on files that are currently modified (could this be handled by a temporary file that contains the git diff... result?)

I've got a somewhat working approach. I chose to modify webpack.base.conf.js instead of going for the command line solution to make use of the already existing string replacement loader.
The files are collected in the WebpackBeforeBuildPlugin callback function and instead of a regex based test variable, a function is used which checks against the previously collected files.
const exec = require('child_process').exec;
const WebpackBeforeBuildPlugin = require('before-build-webpack');
var modFilesList = new Set([]);
const srcPath = resolve('.');
...
rules: [{
test: function(filename) {
let relFilename = path.relative(srcPath, filename);
let lint = modFilesList.has(relFilename);
return lint
},
loader: 'eslint-loader',
include: resolve('src'),
exclude: /node_modules/,
options: {
formatter: require('eslint-friendly-formatter'),
cache: false
}
}, {
... other string replacement loader ...
}
plugins: [
...
new WebpackBeforeBuildPlugin(function(stats, callback) {
// Collect changed files before building.
let gitCmd = 'git diff --name-only --relative | grep -E ".*\\.(vue|js)$"';
const proc = exec(gitCmd, (error, stdout, stderr) => {
if (stdout) {
let files = stdout.split('\n');
modFilesList = new Set(files);
}
if (error !== null) {
console.log(`exec error: ${error}`);
}
});
callback();
})
]
The only problem at the moment is that when git file changes occur, they don't trigger a re-linting based on these file changes (i.e. new file is changed, or previously (before starting webpack-dev-server) changed file changes are discarded). I checked everything I could. The change is registered and stored in modFilesList, the test function is executed and returns true (for a new change in a previously unchanged file) or false in case the change was discarded. I also played with the cache option to no avail. It seems that at initial load, eslint-loader caches the files it will lint in future (don't know if that's a result of using a test function instead of a regex or also the case with the regex). Is anyone having an idea or has seen this before (eslint-loader not updating the file list)?
Update
This seems to be a problem with webpack (or one of the other loaders) as the eslint-loader isn't even executed when the file changed. The test function however is executed which is a bit weird. I don't fully understand how loaders work or how they play together, so there might be some other loader that is causing this...

How to detect whether my code is executed as a Webpack bundle

I'm currently experimenting with the following strategy to dynamically load a json file from a path relative to my module :
If my code is bundled as a Webpack bundle, use import(filename.json)
In any other case, fall back to an AJAX call, with an absolute path
The following seems to work fine :
function parse (fileName, callback) {
var path = "./relative/path/to/" + fileName + ".json";
var cb = process.bind(this, fileName, callback);
if (typeof webpackJsonp !== "undefined") { // <-- Test if run as Webpack bundle
// Do dynamic import
} else {
// Do Ajax call
}
}
However, I can't find any documentation on webpackJsonp, however, so I assume this is not part of Webpack's public API.
I also noticed that webpackJsonp is a function in 3.12 and an Object (inheriting from Array) in 4.28, indicating how fragile it is to rely on the presence, value or type of webpackJsonp.
Is there a (future-proof) reliable way test whether my code is being run as a Webpack bundle, using public API?
Basically, what should I replace typeof webpackJsonp !== "undefined" with, to achieve the same effect, but using public API?
Additionally, I'm also having some problems with getting the actual import to work in Webpack 4.28. See import() breaks in Angular 7.2.3 + Webpack 4.28 for that.

Getting the spec file name into TAP file

we use testem to run our javascript unit tests. As output I get a TAP file, that looks similar like this
ok 1 PhantomJS 2.1 - ABC Directive should contain a template
---
Log: |
{ type: 'log',
text: '\'WARNING: Tried to load angular more than once.\'\n' }
...
lets say, the test is defined ABCItemSpec.coffee. Is there anyway to include this file name in the final TAP output ?
I do not understand much about the javascript/gulp setup her, so the question might be too blurry, but maybe there is a general solution (the way to setup testem, or to give the spec file as argument etc) ?

Is it a bug in SonarQube's JavaScript plugin that it doesn't pick up Surefire test results of tests that are in a subdirectory?

I have a Surefire results directory with 2 files: TEST-Chrome_4202311135_Windows.dashboard.MonkeyTest.xml and TEST-Chrome_4202311135_Windows.PersonTest.xml. Thus, my tests have the following directory structure:
-tests
-PersonTest.js
-dashboard
-MonkeyTest.js
When I run Sonar Runner it picks up PersonTest.js but it says that dashboard/MonkeyTest.js doesn't exist:
18:24:58.747 WARN - Test result will not be saved for test class "dashboard.MonkeyTest", because SonarQube associated resource has not been found using file name: "dashboard/MonkeyTest.js"
Has anybody encountered this? Looks to me like a bug because the file is there.

Well, I've delved into the SonarQube's JavaScript Plugin code to debug it. Found the bug. Looks like this bug only happens on Windows. What the code does is iterates over all the test files, in my case "PersonTest.js" and "dashboard/MonkeyTest.js", and looks for the file "dashboard\MonkeyTest.js". But because "dashboard/MonkeyTest.js" does not equal to "dashboard\MonkeyTest.js" it ignores the results of this test. To be honest iterates over ALL the test files for every test result is inefficient to begin with. Below is the Java method. I'll try to get in contact with the author.
protected InputFile getTestFileRelativePathToBaseDir(String fileName) {
for (InputFile inputFile : fileSystem.inputFiles(testFilePredicate)) {
LOG.warn("Slava: '" + inputFile.file().getAbsolutePath() + "'");
if (inputFile.file().getAbsolutePath().endsWith(fileName)) {
LOG.debug("Found potential test file corresponding to file name: {}", fileName);
LOG.debug("Will fetch SonarQube associated resource with (logical) relative path to project base directory: {}", inputFile.relativePath());
return inputFile;
}
}
return null;
}