My Jenkins job reads lcov file, generated by Istanbul, via Sonar Runner. The numbers/misses in lcov-report generated by Istanbul do not match with that displayed in Sonar. There is 0-7% difference with Istanbul being stricter by finding more misses.
Is it expected? Why the difference?
Environment:
SonarQube 3.5 and 3.7.4
SonarRunner 2.3
Sonar JavaScript plugin 1.6
Node.js code
Coverage% mismatch in a single file shouldn't differ, except for rounding. As for project's %coverage, you'll need to experiment with sonar.exclusions. This is what we're using for a specific Node project:
sonar.sources=.
sonar.exclusions=src/**/*,test/**/*,node_modules/**/*,public/**/*,coverage/**/*,html-report/**/*,views/**/*,Gruntfile.js,*.html
sonar.tests=test
Related
I've recently discovered JHipster and I'm giving it a try. Reading the official web page, it says that JHipster uses Sonar as its linting tool. But I've also noticed that the project has a .eslintrc.json file configured to work with Angular and Eslint dependencies/scripts in package.json. However, the sonar-project.properties file isn't configured to import Eslint's report into SonarQube (via sonar.eslint.reportPaths).
So I'm left wondering how the linting analisis should be done with JHipster's stack. Am I supposed to use sonar-scanner's report or import Eslint's report into SonarQube?
Thanks in advance,
Urko
JHipster uses SonarQube to analyze your java source code and usually this is done by your build tool (maven or gradle) and/or your java IDE.
Then there's static code analysis for frontend code which can be run using npm lint and which uses eslint. JHipster does not configure .eslintrc.json to use eslint-plugin-sonarjs so there's no link with Sonar here but you could add it if you want to use additional eslint rules provided by Sonar.
Having an android library project working fine with AS 4.1.2.
Just installed Android studio (fox) 2020.3.1 patch 3 without change anything (except set the sdk jre to java 8, version 18.6.0_60, since the project is using JavaVersion.VERSION_1_8).
with new AS(fox) the build and run is fine, but the it has issue with unit test and coverage test.
when run unit test, the test will pass but showing some error log:
Caused by: java.lang.IllegalStateException: Cannot process instrumented class com/push/NotificationManager. Please supply original non-instrumented classes.
when try to run the coverage test, it can only do it through the Rnu xxxtest with coverage
not like in AS 4.1.2, it can run the coverage test from Gradle pane/tasks:
also in AS 4.1.2 it could view the coverage test report in the build/report/jacoco folder:
While in new AS(fox) it fails a lot with test events were not not received
and in new AS(fox), in the build/report folder, it could not find the jacoco folder for the result (the html file tells what is the coverage test result, i.e how is branches covered).
the related dependencies:
Gradle: classpath "com.android.tools.build:gradle:4.0.0"
distributionUrl=https://services.gradle.org/distributions/gradle-6.8.3-bin.zip
test:
classpath "org.jacoco:org.jacoco.core:0.8.1"
testImplementation "junit:junit:4.12"
testApi "org.robolectric:robolectric:4.3"
Question
How to resolve the Please supply original non-instrumented classes error in AS (fox)?
How to resolve the test events were not not received?
Where is the jacoco coverage test result html, which shows the coverage percentage details?
Running stack test --coverage generates a nice HTML report showing what lines your test suite covers. How can I achieve the same thing using cabal new-test?
I'm able to pass --enable-coverage to generate a .tix file but I'm not sure what to run on the .tix file to generate the HTML report. I'm pretty sure it involves hpc but I haven't been able to work out the right command.
I have the standard Cabal configuration of my application being a library, with a test-suite for that library.
It appears it's as easy as passing --enable-coverage to cabal new-test. I had previously been running tests with cabal new-run test:test to workaround some limitations of new-test (e.g. lacking streaming and colors), so the fix is to use new-test instead of new-run.
Cabal 3.6 should be able to generate the HPC report. There is one caveat; this error may appear:
Error:
Internal libraries only supported with per-component builds.
Per-component builds were disabled because program coverage is enabled
https://github.com/haskell/cabal/issues/6440
To avoid the error, add to cabal.project:
package *
coverage: True
library-coverage: True
then cabal test (without --enable-coverage). The report should be somewhere in dist-newstyle.
I have my application which runs in Jboss Fuse on Linux. I deploy my artifacts as jar files under the /deploy directory. I was planning to make use of Cobertura to get code coverage report after executing my jmeter tests. I instrumented my jars and placed under /deploy. I ran my jmeter tests.
Now I am unable to find the location where .ser file will be present.
I tried searching inside fuse directory.
Can anyone help me in getting Cobertura working with Jboss Fuse?
For most versions of Cobertura, you can add:
-Dnet.sourceforge.cobertura.datafile=<filename>.ser
to the JBoss/JVM startup parameters (e.g. run.conf) to specify explicitly the file where you want the report to be created.
Also, you need to make sure the cobertura.jar itself is present in the classpath if you haven't done so yet.
I have created a simple project using Node.js, mocha and generated the report for code coverage and unit testing as follows:
mocha -R lcov --ui tdd > coverage/coverage.lcov
mocha -R xunit --ui tdd > coverage/TEST-all.xml
The reports generated using the sonar runner does not reflect the coverage on Sonarqube. The sample test javascript project using LCOV that ships with the sonar-examples-master as well shows 0% code coverage in Sonarqube.
The sonar properties set are as follows:
sonar.language=js
sonar.sourceEncoding=UTF-8
sonar.tests=test
sonar.javascript.jstestdriver.reportsPath=coverage
sonar.javascript.lcov.reportPath=coverage/coverage.lcov
sonar.dynamicAnalysis=reuseReports
Looking forward for inputs on how to resolve this issue and enable the SonarQube to report the coverage on an existing LCOV report.
Thanks,
Neo
JS Test Driver was removed as part of the Sonar Javascript 1.5 release, http://jira.codehaus.org/browse/SONARPLUGINS-3408
So I switched back to the 1.4 plugin.
Regarding the LCOV, I had to match the paths in the LCOV with sonar.sources path.
So
sonar.sources=webapp/app
LCOV was like
SF:webapp/app/path/to/js.js
Hope that helps, I can correct anything I might have gotten wrong tomorrow when I'm at work again.