(TFECO-8268) Enable code coverage reporting #1901
Conversation
This commit enables code coverage reporting for the integration test suites. It uses the `vscode-test` extension's built-in code coverage reporting feature to generate coverage reports for the test suites.
Previously if you were to run `npm run compile` or `npm test`, you would be executing `npm run check-types`, then `npm run lint`, and finally `node esbuild.mjs` or `vscode-test`, respectively, every time you wanted to compile or test the code. This duplication added several seconds to the build or test time. This was unecessary when running interactively, and even more so in CI where these steps were repeated multiple times. This change reduces the number of duplicate steps in CI by running type checking, linting, and formatting only once before compiling or running tests. It also results in a faster run time interactively because we aren't running the more intensive type checking every time. This becomes more important as we added UI testing to the CI pipeline, which is a more intensive process than the other steps.
jpogran
force-pushed
the
enable_code_coverage
branch
from
2960db8 to
4de790f
Compare
jpogran
changed the title
.vscode-test.mjs
Outdated
| thresholds: { | ||
| global: { | ||
| statements: 80, | ||
| branches: 80, | ||
| functions: 80, | ||
| lines: 80, | ||
| }, | ||
| }, |
There was a problem hiding this comment.
| thresholds: { | |
| global: { | |
| statements: 80, | |
| branches: 80, | |
| functions: 80, | |
| lines: 80, | |
| }, | |
| }, |
I couldn't find anything about thresholds in the types or the vscode-test(-cli) repositories. Are you sure that having them here is does anything? Otherwise I would like to remove them to avoid confusion.
There was a problem hiding this comment.
I'm not a code coverage expert, but I play one on TV.
The vscode-test cli doesn't provide the code coverage tooling, mocha provides general code coverage with the ability for other libraries to expand/extend on them.
The thresholds are from when I was trying to get the [nyc[(https://github.com/istanbuljs/nyc) tool to work, but the return on the amount of time required to get it working was not beneficial. I opted to keep the builtin coverage, but neglected to remove the thresholds object. If we were to use another library, options like these would fail the build if they were not met
Co-authored-by: Daniel Banck <[email protected]>
This enables code coverage reporting for the integration test suites. It uses the
vscode-testextension's built-in code coverage reporting feature to generate coverage reports for the test suites.Previously if you were to run
npm run compileornpm test, you would be executingnpm run check-types, thennpm run lint, and finallynode esbuild.mjsorvscode-test, respectively, every time you wanted to compile or test the code. This duplication added several seconds to the build or test time. This was unecessary when running interactively, and even more so in CI where these steps were repeated multiple times.This also reduces the number of duplicate steps in CI by running type checking, linting, and formatting only once before compiling or running tests. It also results in a faster run time interactively because we aren't running the more intensive type checking every time.
This becomes more important as we added UI testing to the CI pipeline, which is a more intensive process than the other steps.