Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SonarQube don't import unit test results anymore #78

Open
americoneto1 opened this issue Feb 8, 2016 · 11 comments
Open

SonarQube don't import unit test results anymore #78

americoneto1 opened this issue Feb 8, 2016 · 11 comments

Comments

@americoneto1
Copy link

The latest version of JavaScript Plugin (2.10) from SonarQube removes the ability to import unit test results using JUnit format, they recommend to use another plugin (Generic Coverage) that uses a different XSD Schema.

Anyone uses this feature? Do you have any solution for that?

It's related to #69

@americoneto1
Copy link
Author

This another reporter is compliance with Generic Coverage Plugin:
https://github.com/tornaia/karma-sonarqube-unit-reporter

@tubbynl
Copy link

tubbynl commented May 4, 2016

the mentioned plugin isn't functional on my project; but imho it is a very good feature for this plugin to comply to the somewhat more strict XSD Schema so SonarQube is supported out-of-the-box with some settings

@americoneto1
Copy link
Author

Sorry, what is imho? Do you import test results from Karma execution to SonarQube using other tool? Which setting do you use?

@fetis
Copy link

fetis commented Nov 30, 2016

I also faced that issue when make integration with Sonar

@r0main
Copy link

r0main commented Jan 13, 2017

Hi,

Is there any plan to support new Sonar format for reporting test result ? https://docs.sonarqube.org/display/PLUG/Generic+Test+Coverage

Reporters out there supporting this new format are not actively maintained. It would be great if the karma team supports it !

Maybe a new plugin to keep backward compatibility with the old format ? Or an option in this plugin asking for format ?

Best regards.

@jpaulin
Copy link
Contributor

jpaulin commented Jan 19, 2017

Good question, whether to keep this plugin as-is and make a new one. @r0main

Anyhow, on the surface, the new Sonar XSD (schema) would mean only changing a couple of strings in the index.js of this plugin.

So if the "rules" themselves are as they were in the older schema, the change is quite small. (Does someone read XSD ? :)

I'll take a shot at it.

@jpaulin
Copy link
Contributor

jpaulin commented Jan 26, 2017

Code ready in PR 117, please try it out and report on findings.

I have validated the new XML being produced by the pull request, against Sonar's XSD schema file. What I would really like to know is does the new XML satisfy a running SonarQube.

Of course also very interested to see whether there's any other issue. Tried to keep everything already working in status quo, ie. not disturb old code.

Two things for testing:
i) add a new config line into karma.conf.js
The essential line is thus the last line in snippet below:

junitReporter: {
      outputDir: './test_out',
      outputFile: undefined,
      suite: '',
      useBrowserName: 'false',
      nameFormatter: undefined,
      classNameFormatter: undefined,
      properties: {},
      xmlVersion: 1
    }

ii) place the new index.js from the pull request, blob below:
https://github.com/jpaulin/karma-junit-reporter/blob/34303edae95d967d06dfd31d91f7b179d3bbcba8/index.js

@tubbynl
Copy link

tubbynl commented Apr 13, 2017

tnx for the effort @jpaulin PR #117 is merged is see 👍

@bmorenc
Copy link

bmorenc commented Apr 18, 2017

Thank you @jpaulin very much for adding this support! I have done some testing and found a couple of open items:
"skipped" tests require a message attribute.
A element is needed with name=full path of test file for each test. Is this possible to get from the karma result?

@jpaulin
Copy link
Contributor

jpaulin commented May 5, 2017

@bmorenc This is good feedback, big thanks. As the code in my PR was rather large, I see that definitely missed these - I had too narrow test coverage, kind of, and thus was only testing for the obvious "positive" cases of test results, ie: 1. test passes or 2. A test fails.
I see there are those issues in the code, will fix these.

@arhohuttunen
Copy link

Thanks @jpaulin for this!

I noticed that the output has: <file path="fixedString">

SonarQube documentation says that this should be either absolute or relative path the the test file.

Is this maybe something that is already being worked on or something that could be contributed with?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants