-
Notifications
You must be signed in to change notification settings - Fork 49
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
feat: add code coverage #93
base: main
Are you sure you want to change the base?
Conversation
Draft proposal of what integrating c8 would look like. I think for now it's probably sufficient to report on the metrics so that we can establish a baseline to build from. Perhaps later on we can begin gating the PRs based on falling below thresholds after we've hit a targeted minimum threshhold. Ive set the value to 75% but I also believe that number should be discussed as well. |
package.json
Outdated
@@ -332,13 +332,15 @@ | |||
"format": "prettier --write .", | |||
"pretest": "npm run compile && tsc -p ./client", | |||
"test": "node ./client/out/test/runTest.js", | |||
"coverage": "c8 --clean --check-coverage --lines 75 npm run test", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're currently using jest
for testing, right? Is there anything c8
gives us that jest doesn't? It looks like they're both using istanbul under the hood
Looks like jest also supports thresholds in a configuration: https://jestjs.io/docs/configuration#coveragethreshold-object
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont have a strong opinion on which one we choose. If we already have jest as a dependency (looks like we do) then we can reuse what we have.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the extension test api uses mocha. Jest-Worker is being pulled in transitively, but the dev dependencies also support the mocha theory:
"devDependencies": {
"@types/mocha": "^10.0.1",
"@types/node": "^18.11.18",
"@typescript-eslint/eslint-plugin": "^5.48.1",
"@typescript-eslint/parser": "^5.48.2",
"c8": "^7.12.0",
"chai": "^4.3.6",
"esbuild": "^0.13.15",
"eslint": "^8.31.0",
"media-typer": "^1.1.0",
"mocha": "^10.2.0",
"path-browserify": "^1.0.1",
"prettier": "^2.7.1",
"ts-loader": "^9.4.2",
"typescript": "^4.4.3",
"webpack": "^5.75.0",
"webpack-cli": "^5.0.1"
}
Based on the original stackoverflow post from the issue, it looks like when using mocha that an additional library is needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another interesting data point to look at use trends for the 3 popular ones, nyc, c8, and istanbul:
Specifically with respect to downloads and the frequency for which the libraries are being updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@2TomLi asked me to quick take a look at this since I've done a good amount of work on jest in other projects. I'm not familiar with this project though so if I miss something, sorry.
As @smorrisj was saying, this project, as best as I can see, is using mocha and I don't see any support for coverage directly from mocha like we get with jest. Using either c8 or nyc seems like an easy setup. istanbul doc says nyc is basically the istanbul CLI so you're left with just c8 or nyc. Both c8 and nyc seem popular enough to use and find support if needed. Both integrate the same way. So if y'all decide one isn't good, it should be an easy swap to the other.
It's great. I looked at the build log |
Great points. I started out taking the defaults to see where we'd want to tailor the config. I'll add a .c8rc to frame further discussion around configs. |
.c8rc
Outdated
@@ -0,0 +1,6 @@ | |||
{ | |||
"all": true, | |||
"include": ["client/out/**"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@scnwwu Which directories from lsp server should be included here? Is src sufficient? I suspect data and pubsdata are not needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think src should be good.
BTW., for client, why not "client/src" but "out"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The coverage counters act upon the transpiled output from what I've experimented with. When I changed it to only include client/src/** and server/src/**, c8 didnt output any coverage data in the report. Based on this is it still appropriate to exclude dist from server directory?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the information. I don't have much knowledge about it. I'm confused about why it can count the files in "client/out". The tests run on VS Code which will run the "client/dist/node/extension.js" file. The files in "client/out" is not used except test files. Perhaps only including "dist" directory should be enough?
Also, I guess the files in "connection/rest/api" can be excluded as they're generated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I see. Looking at the coverage report, the "node/extension.ts" file shows 0. So it only counts the files that directly imported from the tests. So I guess both "client/out" and "client/dist" should be included, hopefully it can aggregate the coverage. And for server "server/dist" should be good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@scnwwu thanks, will update the includes to add these.
A reminder, this change will add some new files to the workspace. Before merge, please update the |
Will update the |
.c8rc
Outdated
@@ -0,0 +1,6 @@ | |||
{ | |||
"all": true, | |||
"include": ["client/out/**"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the information. I don't have much knowledge about it. I'm confused about why it can count the files in "client/out". The tests run on VS Code which will run the "client/dist/node/extension.js" file. The files in "client/out" is not used except test files. Perhaps only including "dist" directory should be enough?
Also, I guess the files in "connection/rest/api" can be excluded as they're generated.
@@ -15,3 +15,6 @@ prettier.config.js | |||
contributing.md | |||
ContributorAgreement.txt | |||
.travis.yml | |||
.eslintignore | |||
.eslintrc.js | |||
.c8rc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does coverage/
need to be added here too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@scnwwu agreed, will add that to the list here.
package.json
Outdated
@@ -332,13 +332,15 @@ | |||
"format": "prettier --write .", | |||
"pretest": "npm run compile && tsc -p ./client", | |||
"test": "node ./client/out/test/runTest.js", | |||
"coverage": "c8 --clean --lines 75 npm run test", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as there's a config file now, do we want to move --lines config into the config file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@scnwwu thanks. Agreed. will add that to the .c8rc
package.json
Outdated
@@ -332,13 +332,15 @@ | |||
"format": "prettier --write .", | |||
"pretest": "npm run compile && tsc -p ./client", | |||
"test": "node ./client/out/test/runTest.js", | |||
"coverage": "c8 --clean --lines 75 npm run test", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, another question, looking at current log
https://github.com/sassoftware/vscode-sas-extension/actions/runs/3997580900/jobs/6859100928
It shows 42.67% lines for "All files". Why the build didn't fail as it requires 75%?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@scnwwu I am not using the check-coverage flag. Without the check-coverage flag it will just list the coverage numbers in information mode and not fail the build. I thought for the first iteration this would be best, so that we can make targeted efforts to bring the numbers up. After the numbers are up we would enable the check-coverage option so that new changes that cause the threshold to fall below 75 percent would fail?
0ae3e0e
to
5d1c3fa
Compare
@@ -0,0 +1,7 @@ | |||
{ | |||
"all": true, | |||
"src": ["client/src", "server/src"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little confused. Does this src
setting really take effect? If so, sounds like "client/out/test/" doesn't need to be excluded as it won't be included? I looked at latest build log, tools/build.mjs is also in the report.
I looked at the latest build log. It looks still confusing. It shows both |
I think it's still important and should be implemented. Other priorities have pulled me away from looking into it further. See @scnwwu's latest comment. I think if we could get answers to those, maybe it would be enough to make small adjustments to what's there to finish it up. |
VS Code's test-cli already integrates c8, maybe worth a look when anyone pick this up |
Summary
Draft proposal to integrate c8 coverage tool for tests
Testing
-close all running vs code instances
-from terminal run "npm run coverage"
-verify that the expected extension tests run and that counters are output at the end