Split the coverage report
Closed this issue · 3 comments
Is there any chance we could split the coverage report between the files changed and the whole test suite?
It's not implemented right now, but I'll happily accept a PR that does this.
My first Idea was to have all the changed files come first in the table of files (maybe with a multi-column-span headline), e.g.:
| File | Stmts | % Branch | % Funcs | % Lines | Uncovered Lines |
|---|---|---|---|---|---|
| Changed Files | |||||
| changedfile.js | 100% | 100% | 100% | 100% | |
| changedfile2.js | 100% | 100% | 100% | 100% | |
| Unchanged Files | |||||
| unchangedfile.js | 100% | 100% | 100% | 100% | |
| unchangedfile2.js | 100% | 100% | 100% | 100% | |
What do you think? Or would you also require the summary only for the changed files?
I would do both, adding the summary for the changed files and a section for these files in the details as suggested.
In my case at least, we are working on a project which has a huge lack of tests and we want to improve it - so ideally every new PR should have a high level of code coverage in the changed files but mainly not drop the overall coverage of the application!
The goal would be to display how well covered is the upcoming code and still give the dev an overview on how is he improving the overall application test coverage.
Coverage Summary
| Status | Category | Percentage | Covered / Total |
|---|---|---|---|
| Changed files (this could be enabled by a configuration flag) | |||
| 🟢 | Lines | 91.2% / 90% | 450 / 500 |
| 🟢 | Statements | 91.2% / 90% | 450 / 500 |
| 🟢 | Functions | 91.2% / 90% | 450 / 500 |
| 🟢 | Branches | 91.2% / 90% | 471 / 500 |
| Overall application | |||
| 🟢 | Lines | 84.66% / 81% | 1176 / 1389 |
| 🟢 | Statements | 84.2% / 80% | 1194 / 1418 |
| 🟢 | Functions | 83.62% / 80% | 286 / 342 |
| 🟢 | Branches | 72.46% / 70% | 471 / 650 |
File Coverage
The table you suggested hereWhat do you think?
If you agree I am happy to help! If you have any guide on how to test it, it will be the first time I would be contributing to GH action repo. Should I fork, open a PR in my fork and test the updated action through there?
If you know any article that could help me there I would appreciate - otherwise I will dig into GH Actions docs and find my ways.
Hi @bissolli - I still don't have Contribution Guidelines, so I will add these. 😅
For now it's the usual process:
- Fork the repository
- Create a new branch onto where you develop the feature
- Open up a pull request from the branch of your fork
There are some unit-tests included that you can run with npm run test (don't forget to npm install before). They are not super sophisticated yet unfortunately.
To fully test it 'locally', you can also just put up a PR onto your forked repository with your changes, and the action should just execute itself.
If you have any questions feel free to just ask, happy to assist you here! 👍🏻