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

Packages is N/A with cobertura report if test files is under one folder #66

Closed
flyHe opened this issue Jun 12, 2017 · 19 comments · Fixed by #571
Closed

Packages is N/A with cobertura report if test files is under one folder #66

flyHe opened this issue Jun 12, 2017 · 19 comments · Fixed by #571
Labels

Comments

@flyHe
Copy link

flyHe commented Jun 12, 2017

moved from istanbuljs/nyc#598 (comment)

Please use the template provided below, when reporting bugs:

Expected Behavior

Packages should be 100% with cobertura report if test files is under one folder
The right cobertura xml file should be as below (generated by istanbul directly):

screen shot 2017-06-07 at 4 39 47 pm

Observed Behavior

Packages is N/A with cobertura report if test files is under one folder

screen shot 2017-06-07 at 4 21 36 pm

screen shot 2017-06-07 at 4 39 54 pm

Bonus Points! Code (or Repository) that Reproduces Issue

Forensic Information

Operating System: OS X Sierra 10.12.5
Environment Information: node 6.10.3, npm 3.10.10

@amerryma
Copy link

Seeing this as well! 👍

@bcoe
Copy link
Member

bcoe commented Jul 22, 2017

@amerryma @flyHe I'm not too familiar with the cobertura test reporter. Would either of you be able to provide an example repo that reproduces this issue? ideally with expected output, vs. observed output?

At which point, happy to start digging into the issue (or to accept any patches you make to address the issue, if you feel like doing some digging yourselves).

@bcoe bcoe added the triaged label Jul 22, 2017
@flyHe
Copy link
Author

flyHe commented Jul 24, 2017

@bcoe I have created an example repo in https://github.com/flyHe/testSample

@ivailop
Copy link

ivailop commented Aug 1, 2017

Just FYI, I believe this issue is exactly the same as #14. Notice there was also a similar Clover report problem - #13.

I'm sorry I had no time confirming either of them when they were considered to be fixed.

@bcoe
Copy link
Member

bcoe commented Aug 1, 2017

@flyHe thank you I appreciate the sample repo; if anyone beats me to it, would love help digging into the underlying issue with the cobertura reporter.

@jhillacre
Copy link

I can get a valid cobertura,xml report generated by commenting out these lines:

this seems to confirm @JaKXz's statement from the nyc issue

My completely blind guess is that the cobertura reporter needs to print something when you do not have multiple subfolders for the Resource name.

I'm not sure the history of why those statements are there. It seems to me weird that the onDetail method doesn't have the same guard.

@sureshappana
Copy link

I am facing similar issue (using nyc though).

Scenario1 I tested:
as per the above comments I tried placing the tests and scripts in same folder and tested this. Still I am getting different format of cobertura report (when I excluded the spec.js from nyc exclude)

Package.json:

"nyc": { "exclude": [ "coverage", "**/*.spec.js" ], "reporter": [ "html", "text-summary", "cobertura" ], "all": true }

Scenario2 I tested:
scripts and tests are in different directory. Corbertura report correct format generated only when I don't mention the spec files in exclude list.

After I tested multiple other approaches, in my case root cause of issue is excluding spec files in test, I don't want the coverage report of test files in report.

@jjscaria
Copy link

Is there an update on this issue?

@acesiddhu
Copy link

seeing same behavior with this repo
https://github.com/MicrosoftDocs/pipelines-javascript
more details on istanbuljs/nyc#965

@JaKXz
Copy link
Member

JaKXz commented Feb 13, 2019

Would someone here be willing to try to contribute a failing test in a PR? :) that would get the ball rolling quickly

@jjscaria
Copy link

Is it possible to implement the fix from #14 here?

@coderica
Copy link
Contributor

This is a really hideous and subtle issue. thought i'd try to kick fixing it into gear.

@bcoe
Copy link
Member

bcoe commented Apr 30, 2019

@coderica very much appreciate the help digging into this 👍

@coreyfarrell
Copy link
Member

Fixed in #382

@coderica
Copy link
Contributor

@coreyfarrell this issue should be reopened since it has not been resolved 😞

@coreyfarrell
Copy link
Member

Sure just be aware it is up to the community to provide a patch for this issue, istanbuljs maintainers are unable to provide a fix.

@coreyfarrell coreyfarrell reopened this Sep 30, 2019
@chris-redekop
Copy link

@coreyfarrell Thanks for the last comment. I'm just hitting this problem now and found this issue 66. I'm not sure what you mean,

it is up to the community to provide a patch for this issue, istanbuljs maintainers are unable to provide a fix.

  • Maybe this is an upstream issue, and so is out-of-scope for the istanbuljs maintainers?
  • Maybe the istanbuljs maintainers do not have the bandwidth to provide a fix?

Do you think this issue can be fixed in this repo, or are you recommending that it be fixed upstream?

@coreyfarrell
Copy link
Member

It's an issue of knowledge, istanbuljs maintainers do not know what should be produced by the Cobertura report. I suspect the issue is in this repository, specifically in https://github.com/istanbuljs/istanbuljs/blob/master/packages/istanbul-reports/lib/cobertura/index.js.

@chris-redekop
Copy link

Thanks for the quick and helpful clarification.

coreyfarrell added a commit that referenced this issue Jan 11, 2020
saboya added a commit to saboya/webpack-chrome-manifest-generator-plugin that referenced this issue Jun 16, 2020
@bcoe bcoe closed this as completed in #571 Oct 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.