Is there a way to get deno coverage information in a vscode lens?
If I run my tests with coverage enabled, can I get some visual feedback in vscode?
10 Replies
I wasn't able to find the answer to your question in the official Deno documentation. As of my last update, there isn't a specific Deno feature or extension that provides test coverage information directly in VSCode as a CodeLens.
However, if you're looking for visual feedback on your test coverage in VSCode, you might consider generating a coverage report using Deno's built-in coverage tools and then using a generic code coverage visualization tool that supports the output format provided by Deno.
To generate a coverage report with Deno, you would typically run your tests with coverage enabled like this:
After running your tests, you can convert the coverage data to a more common format like lcov:
Then, you could use a VSCode extension that supports lcov reports, such as "Coverage Gutters", to visualize the coverage in your editor.
Please note that this advice is not based on the Deno documentation, and I would advise you to double-check the accuracy of this advice and the compatibility of any VSCode extensions with Deno's coverage output.
Works fine if I generate .lcov and use https://marketplace.visualstudio.com/items?itemName=markis.code-coverage !
Code Coverage - Visual Studio Marketplace
Extension for Visual Studio Code - Boost test coverage and reliability with this easy-to-use code coverage analysis tool
Hmmm… What does it mean that the highlighted line is missing coverage? It's just a closing brace.
That one probably means the
else of that if wasn't covered.
I think may be a couple off-by-ones in the coverage info, particularly around branches. I'll bet it's in the generated TS sourcemaps, but I can't prove it until I isolate some test cases.Thanks!
I wish I could generate coverage when I run tests from the code lens…
Me too. I also wish debugging was easier from there.
Right. Debugging stuff in the js runtime of Deno was a nightmare tbh. I spent hours on a trivial issue I only found after I just injected debug information in the global scope so I could inspect things by running the generated deno binary……
(turns out object keys are always coerced to strings even if they're numbers, duh 😄 )
(you almost certainly know this, but use a Map if you want numbers, and wait patiently for https://github.com/tc39/proposal-record-tuple so that both Map and Set are actually useful one day)
GitHub
GitHub - tc39/proposal-record-tuple: ECMAScript proposal for the Re...
ECMAScript proposal for the Record and Tuple value types. | Stage 2: it will change! - GitHub - tc39/proposal-record-tuple: ECMAScript proposal for the Record and Tuple value types. | Stage 2: it w...
FYI @kt3k is investigating problems with coverage - there's something wrong with source maps being applied and that's why you see these strange uncovered lines
Can you open an issue about it? Seems like adding an option to capture coverage from a code lens shouldn't be too hard
Could you open an issue for that too? Debugging is really important to us, so if something is not easy to do we will address it
Sure! https://github.com/denoland/vscode_deno/issues/1018
Which repo should I create that one in? The main repo, right?
Edit: https://github.com/denoland/deno/issues/21652