SonarQube, sonar-javascript and JSTestDriver - ressource not found - javascript

I need your help/guidance about one problem I have for the last two days.
The sonar-javascript plugin is not able to get the results of my Javascript UnitTests. I am generating unit tests and lcov results using JSTestDriver. The lcov results are working and are correctly shown in SonarQube. I also have to say that I am using Windows. Here is the error I have:
Test result will not be saved for test class "UnitTests.controlesTest", because SonarQube associated resource has not been found using file name: UnitTests\controlesTest.js"
The error is very similar to this one: Importing javascript XML JUnit tests to sonar using jstestdriver fails. However, this error seems to be fixed in the last SNAPSHOT (2.8). The file I am trying to access is stored in UnitTests/controlesTest.js. I tried to go into the sonar-javascript source, and find a way to correct this issue (at least, try to understand it). I ended up in the file JsTestDriverSensor.java in the function getTestFileRelativePathToBaseDir. I found that this line is not able to get my file (UnitTests\controles.js). Actually, fileIterator does not contain any InputFile.
Iterator<InputFile> fileIterator = fileSystem.inputFiles(predicate).iterator();
So I tried different predicates to understand why my file is not found. At the end, I found that the following predicate fileSystem.predicates().hasType(InputFile.Type.TEST) is the reason why this file is not found. A quick fix is to change:
- 108 testFilePredicate,
+ 108 mainFilePredicate,
I must be doing something wrong, maybe someone has an idea ?

The "sonar.tests" property has to be set in the sonar-project.properties (or in newer version SonarQube.Analysis.xml). This allows the sonar-javascript plugin to find the javascript test files.

Related

Emscripten: 'undefined symbol' when calling JavaScript from C/C++; ERROR_ON_UNDEFINED_SYMBOLS does not work

Actually I've two questions, because the common workaround for my initial problem does not work :)
I'm trying to build an Emscripten based library which calls JavaScript functions as described here: https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#implement-a-c-api-in-javascript
Simply put I just implement my C/C++ code against a C-Function, implement that function in a .js file and 'link' that file using --js-library.
Basically things are working for me except with version EMSDK version 1.38.12 I got a warning when linking the final library:
warning: undefined symbol: foo_
.. which I don't understand but I could just ignore it. In newer versions of EMSDK the behavior changed and the warnings become errors.
Searching for this error you find you can just add -s ERROR_ON_UNDEFINED_SYMBOLS=0 when linking, but this doesn't work (for me) - I still get this error despite I can see this option being added to the linker.
So my questions are:
how do I make -s ERROR_ON_UNDEFINED_SYMBOLS=0 work for me?
and why do I get this warning in the first place? how do I get rid of it?

Not able to access variable in google chrome console

I am using the latest version of Meteor js. I am a newbie and couldn't find the solution. I have surfed for this problem a lot.
Before going to the problem, please have look at the directory structure first.
My directory structure of the project is like this :
\client
\main.html
\main.css
\main.js
\imports
\lib
\todos
\todos.js
\server
\main.js
I have created a Mongo Object in todos.js.
export const Todos = new Mongo.Collections('todos');
This is working fine.
Now in client\main.js, I am importing this object,
import { Todos } from '\imports\lib\todos\todos.js';
Note: I tried relative and absolute both type of addressing.
I put a debugger after that and checked and the variable is there. I can access that variable on the console. But as soon as I pass the statement and all the code is rendered on the browser(google chrome), I am not able to use Todos. It is giving me a ReferenceError. The error is
Todos is not defined.
I know there is no problem till the browser is loading because I checked that. I have surfed a lot. Please help me.
Thank you in advance.
Edit 1: I am using windows 7 if that is necessary.
As the comments above said, variables declared or imported in a file/module don't end up on the developers console.
What you can do to get stuff on the console is import it to the console using require
> require('/imports/lib/todos/todos.js')
Any valid absolute path or package will work here
Note: the path separators are always *nix style /
I had a similar problem while trying to evaluate moment from Moment.js in Chrome console. It was imported by the script being debugged/under breakpoints but does not work in console. import or require Moment.js in console gave me errors and did not work for me.
I ended up switching to Firefox Developer Edition, where I can put breakpoints and then evaluate moment in its console out of the box without any problems.

Anchor element's pathname returns undefined in Rhino with env.js

I have run into an issue that I believe is rooted in the implementation of anchor tags in Rhino. Although I am utilizing env.js, I suspect perhaps I am not configuring something correctly.
In particular, my issue occurs while I am attempting to write unit tests against code written for an angularjs application. When I include angular.js (versions 1.2.1 to present), I get the following error:
TypeError: Cannot call method "charAt" of undefined
I am convinced the error is the result of this call to urlParsingNode.pathname since a console.log call reveals that the pathname object is undefined.
I traced the instantiation of the urlParsingNode to this line where we see that it is the result of a call to document.createElement("a"); Further down, we see that they set the href attribute in this line in hopes that the created anchor tag will utilize the browser to correctly parse the URL.
I have to believe I'm not the first to attempt JS unit testing for angular via Rhino, but thus far I've not successfully Googled myself to a solution. Any tips will be greatly appreciated.
Found it and fixed it. The pathname getter/setter simply was undefined for HTMLAnchorElement in env.js.
I submitted a pull request, but unfortunately the project looks all but abandoned. I also couldn't figure out how to build it out to a single file. It appears perhaps someone has taken it upon themselves to break it apart into require.js modules. Not a battle worth fighting for my use case.
So for anyone else who hits this issue, I have the code you need below. It belongs in the HTMLAnchorElement.prototype. In my copy of env.js 1.2, this prototype begins on line 8075. I added the following at line 8118.
get pathname() {
var uri = Envjs.urlsplit(this.href);
return uri.path;
},
set pathname(val) {
var uri = Envjs.urlsplit(this.href);
uri.path = val
this.href(uri.urlunsplit(uri));
},
FYI, my particular issue is resolved with this pull request.

js-test-driver + coverage plugin crashes on javascript 1.7 statements

Trying to add tests support into my project. Attached JsTestDriver with coverage plugin.
Dummy tests are working correctly, but when I load up all my source files I'm getting application crashed with the following:
[java] **line 109:12 no viable alternative at input 'formFound'**
[java] Exception in thread "main" com.google.jstestdriver.coverage.CodeInstrumentor$InstrumentationException: error instrumenting /path/discover.js
[java] at com.google.jstestdriver.coverage.CodeInstrumentor.instrument(CodeInstrumentor.java:74)
[java] at com.google.jstestdriver.coverage.CoverageInstrumentingProcessor.process(CoverageInstrumentingProcessor.java:62)
This line of code looks like:
let formFound = tryToFindLoginForm();
I changed that definition into
var formFound = tryToFindLoginForm();
After that JSTD will pass over that string but will die on next let statement. Is there any way to workaround this, to tell JSTD the version of javascript used in code or something?
It'll be a very big issue to rewrite entire code into version without lets.
Thanks for help in advance.

SonarQube always displays 0.0% code coverage for Javascript project

I am new to SonarQube, and am trying to use it with a Javascript project, on Windows. I've followed the doc as best I can and am successfully seeing the static code analysis sonar does.
I am using JsTestDriver for my unit tests, and producing a code coverage report file. I see the test results in SonarQube, but the code coverage is always reported as 0.0%. If I don't specify a code coverage report file, or specify a file name that doesn't exist, the code coverage block in my dashboard does not display at all, so I know Sonar is seeing the file in some sense. I have run jGenHtml against the file and it produces correct HTML output, with the results I expect, so I know the file has content and is formatted correctly.
I have specified the location for these files in my Javascript plugin settings. As indicated by the doc and some forum posts I found, I used the relative directory path test/results for the actual unit test results (which show up fine) and the relative file name test/results/code-coverage.dat for the coverage report. I've also tried specifying the file as an absolute path, but it didn't help.
Any insight would be appreciated.
This is working now, thanks to the suggestion comment from David RACODON.
It seems my code coverage report contains file paths that look like this:
SF:H:\perforce_workspaces\atlasjs_main\.\test\lib\jquery-1.8.2.js
I edited the file to remove the \.\ bit in the middle, and now Sonar is able to import the file.
The sample project's coverage report does not have this in its paths, and I note that I have been using a slightly newer verson of jsTestDriver than the sample app. I am using 1.3.5, while the sample app comes with 1.3.4.b. I don't know if they changed the output format between revisions of the coverage plugin, or if this is something specific with my project. In any event, I should be able to figure out a way to prevent or remove the offending characters.
Note that jgenhtml was able to read my file just fine with the extraneoud \.\ so this seems to be an issue with Sonar being very picky.

Categories