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

[BUG]Code coverage with "all" option does not report uncovered source code #24389

Closed
xiamingwei opened this issue Jul 25, 2023 · 7 comments
Closed

Comments

@xiamingwei
Copy link

xiamingwei commented Jul 25, 2023

System info

● Playwright Version: [v1.31.2]
● Operating System: [macOS 12.0.1 MacBook Pro M1.]
● Browser: [Chromium]
● Other info: i am using the official recommended code coverage instrumentation library, playwright-test-coverage you can see it in (#7030)

Source code
(https://github.com/xiamingwei/umi-e2e-test/blob/main/e2e/index.spec.ts)
I will provide a minimal repository to reproduce this issue

Steps
tnpm i
tnpm run e2e
npx nyc --all report --reporter=html --reporter=json-summary --reporter=json

Expected
in the index.html file located in the generated coverage folder,All files in the application should be displayed, but only the files covered by the test cases are shown. because i also have other modules like Home.tsx,Detail.tsx etc...
image
image

Actual

image
In fact, only the files mentioned in the test cases are displayed,this will cause a phenomenon that when I add test cases for other pages, the new test cases will also be included in the coverage report, leading to a decrease in the original coverage rate.

@pavelfeldman
Copy link
Member

Please follow the issue template and provide something we could reproduce so that we could act on the issue. It is unclear what does not work and what you are doing to trigger the behavior otherwise.

@xiamingwei
Copy link
Author

Please follow the issue template and provide something we could reproduce so that we could act on the issue. It is unclear what does not work and what you are doing to trigger the behavior otherwise.

I'm sorry that my previous question was not good. I have provided a minimal reproducible GitHub repository. Please run it as mentioned, and you can see the results. Thank you very much. @pavelfeldman

@pavelfeldman
Copy link
Member

I did not realize you are using playwright-test-coverage, it is not a part of Playwright and is by no means official, you should file this against their repo!

@xiamingwei
Copy link
Author

xiamingwei commented Jul 27, 2023

I did not realize you are using playwright-test-coverage, it is not a part of Playwright and is by no means official, you should file this against their repo!

Ok, i am sorry, is the method https://playwright.dev/docs/api/class-coverage#coverage-start-js-coverage recommended by the official documentation?"Yesterday I investigated and found that the reason was due to lazy loading of the routing module, which resulted in only the involved modules being counted. Do you have any good suggestions to solve this problem?

@pavelfeldman
Copy link
Member

Ok, i am sorry, is the method https://playwright.dev/docs/api/class-coverage#coverage-start-js-coverage recommended by the official documentation?

This method is a part of Playwright, yes, it exposes raw V8 code coverage on Chromium.

Yesterday I investigated and found that the reason was due to lazy loading of the routing module, which resulted in only the involved modules being counted. Do you have any good suggestions to solve this problem?

which resulted in only the involved modules being counted.

That's the point of the coverage, it only shows what's actually used. Or do I not follow the question?

@xiamingwei
Copy link
Author

xiamingwei commented Jul 28, 2023

In our context, code coverage is measured based on the total amount of code.Because when I only wrote test cases for page A, and the code coverage was very high. But when I added test cases for page B which I haven't tested before, the code coverage dropped again,it`s not stable. Or When new features are added, the total denominator increases. If the existing test cases remain the same, the code coverage will decrease, which is meant to remind developers to supplement the test cases.We also looked into nyc, but found that its support is also based on the non-lazy loading of page modules, rather than routing modules.Thank you again for your response. Our plan is to abandon lazy loading of the routing module, which can solve this problem.If you have any further thoughts, we can continue the discussion. Otherwise, we can close this issue. Thank you again @pavelfeldman.

@pavelfeldman
Copy link
Member

Closing as per above, please feel free to open a new issue if this does not cover your use case.

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

2 participants