atlaste / cppcoverage Goto Github PK

Visual Studio Extension for measuring C++ Code Coverage and profiling data

C++ 3.87% C 1.65% C# 1.32% POV-Ray SDL 93.15%

cppcoverage's Introduction

Free C++ Code Coverage

CPPCoverage is a Visual Studio extension that calculates code coverage and profile data for C++ applications and Visual Studio C++ native tests. Basically it provides you with an easy-to-use, light-weight C++ code coverage and profiler, right from Visual Studio and with the features you expect from tools like these.

Installation

Prerequisites: VS2013 or VS2015. Any edition should work, even though this is only tested on VS2015 Community.

Install this extension: https://github.com/atlaste/VSOpenCPPCoverage/raw/master/CoverageExt/CoverageExt.vsix .

Getting started

Working with CPPCoverage is a breeze. Basically install and use, there's nothing more to it:

Either create a standard C++ / MS Test application, or run a simple C++ / console application. Note that OpenCppCoverage assumes that there is no user input during the test run.
Build your solution in Debug mode. Make sure to compile with '/DEBUG'; '/DEBUG:FastLink' is currently unsupported .
Right-click in solution explorer on the test or application project, click "Run code coverage".
Open a file that you want to show coverage info for. If the file is already open, close it and open it again.
For an overview, go to Tools -> Coverage report
Coverage is measured in a background thread. Watch the output window to see when it's finished.

Features

Highlighting covered and uncovered code directly from Visual Studio:

Report generation of covered code (Tools -> Coverage report):

Run code coverage on VS unit tests (Right click VS project -> Run code coverage):

Hide code from code coverage results using #pragma DisableCodeCoverage and #pragma EnableCodeCoverage:

Sampling-based profiling data is gathered as a by-product

IsDebuggerAttached is overwritten with 'return false' so that you can distinguish between debugger and test sessions.
The CodeCoverage output window will give you the current status of the process. Stdout is forwarded here as well.
Small memory footprint and very fast. Even if you have a million lines of code, CPPCoverage will only use kilobytes of memory for coverage.

Experimental Features

Static code analysis can be enabled, to get rid of if-then-else quirks.
In your test code, you can tell the coverage tool to ignore files and folders. So, everything is handled from code; no pesky configuration files need to be managed.

For an overview of these runtime notifications.

Support and maintenance

CPPCoverage is 100% open source and 100% for free.

At NubiloSoft, we use this CPPCoverage addin on a daily basis in a real environment on a huge C++ code base. We want this to be good. And since this is not our core business, we are willing to make it available for free. Simple as that.

Over the period that we've used this extension, it has proven to be both reliable and stable, resulting in only a very few issues and very little work for us to maintain it. However, if you do find a bug or think the tool lacks a feature, please let us know by posting it in 'issues'.

Profile data

Our profile data is gathered in a very simple way: every 5 milliseconds we simply force a context switch, after which we gather the stack trace. For the entire stack trace, we then update the number of times that line has been hit (both for the top-most frame and for all frames). We only consider code that is available; performance is not measured for third-party libraries, even if the PDB is available.

This process will give us two numbers, that are shown in Visual Studio:

The percentage of time the method spends on this line of code. Note that if this is a function call, the time spent could be very high.
The percentage of time the application spends on this specific line of code. This is excluding function calls, so most lines will have very low numbers.

For those familiar with the tools, this is pretty similar to what tools like Sleepy and Very Sleepy do.

As an example, if you spot "50%/20%" after a line of code, this basically means that 50% of the time is spent on this line of code (or in one of the child function calls) and 20% of the time is spent on this line of code (in total).

If profile information is insignificant (e.g. 0%), we simply won't show it. You might ask yourself: why 5 milliseconds? Well, simply put, context switches have a serious impact on performance, and this appears to be the sweatspot where the tool doesn't have significant impact on the performance of your test.

If the tool doesn't work...

There are a few likely suspects to check:

Check the Coverage output window in Visual Studio!
Have you loaded a solution?
Are PDB's available? Can you debug the application? If not, code coverage won't work.
If your (Native unit test DLL) unit tests aren't running in Visual Studio, they're also not running in the coverage tool. Obviously this is the same when you're using an executable.
Is all your source code in a child folder of your solution? If not, you can run Coverage-x86 or Coverage-x64 as executable and store the output in the solution folder. Basically the recipe is as follows:

[install folder]\Resources\Coverage[-x86 / -x64].exe -o "[solution folder]\CodeCoverageTest.cov" -p "[root path of your code; omit the trailing '']" -- "[executable to run...]" [... optional arguments...]

Advanced users

Most people want to integrate code coverage in their test environment. Coverage-x86.exe and Coverage-x64.exe will provide just that. We support emitting Cobertura XML files, which can be processed by a lot of tools.

If you want even more control, grab the code from the Coverage project, change the executable that's executed and you're done.

Measuring code coverage

In a nutshell, our test tool measures everything by creating a debugger process and putting breakpoints on every line of code. After a breakpoint has been hit, the breakpoint (assembler) instruction is removed from the program again. This breakpoint process has only a tiny bit of overhead, because it basically relies on a single context switch per breakpoint. Also, this means that the amount of memory that you need is roughly bound by the number of lines in your application.

In the early versions of this tool, we've used OpenCPPCoverage as an external dependency. And even though OpenCPPCoverage is pretty decent, we feel it just cannot deliver everything that we need. Therefore we've been working on a better alternative, which is available now:

OpenCPPCoverage seems to be pretty heavy. We wanted something that's fast as hell, since we're measuring all the time.
The relevant #pragma's are handled by the coverage tool, so that files are properly ignored by the coverage engine.
We're working with production-grade software, so we want the memory footprint of out coverage tool to be very small.
We want integration in our test suites. It makes little sense to run a separate memory leak checker, a separate coverage checker and a separate unit test runner. We want all those things at once.
Better handling of filters for "normal" solutions. We want to measure coverage on our solution, nothing more and nothing less.
IsDebuggerAttached is giving us a hard time. We've implemented a nice workaround for this in the new coverage tool.
We found that a lot of time was spent writing Cobertura files. Even though the new coverage tools support Cobertura XML files, it's not preferred. We've created a new text-based file, which is way smaller and more suitable for code coverage.

The projects Coverage-x86 and Coverage-x64 are the result of this, which provide this new coverage tool. For the most part it already works great; for most applications you don't even notice that coverage is being measured.

Templates, templates...

If you have templated code, code coverage will be measured for any of the templates. This was not an easy decision, after all: if you have a different template parameter, you actually end up with different code. Still, if the specialization for type A and type B will run the same code, we find it unlikely that the quality of your tests is affected (just because you test A and not B). In most (but not all!) cases, we believe it's the coverage of the members of A and B that you call that tell the story.

In fact, our Coverage engine measures this and emits 'p' for 'partial coverage' in the results.

So... in short: if a template specialization is hit, we'll mark the line as green, regardless if all possible template arguments are tested or not.

License

Your friendly BSD license. Please give credits where credits are deserved.

cppcoverage's People

Contributors

Stargazers

Watchers

Forkers

zhouliangyi rominitch malickf codeasgard tjrileywisc hugmyndakassi exoosh awesomevsplugins phunm211 nickledeg angieeve patha9 linarcx zxffffffff sportacandy jgshumate1 mantoniak

cppcoverage's Issues

Small random bug that pops up with GIT integration

It's interesting what you sometimes find in the Activity log:

System.ArgumentNullException: Value cannot be null. Parameter name: key at System.Collections.Generic.Dictionary2.Remove(TKey key) at OpenCppCoverage.VSPackage.CoverageTree.CoverageViewManager.OnTextChanged(IWpfTextView textView, TextContentChangedEventArgs e) at OpenCppCoverage.VSPackage.CoverageTree.CoverageViewManager.<>c__DisplayClass9_0.<TextViewCreated>b__0(Object sender, TextContentChangedEventArgs e) at Microsoft.VisualStudio.Text.Utilities.GuardedOperations.RaiseEvent[TArgs](Object sender, EventHandler1 eventHandlers, TArgs args)

When you get this, you'll encounter a nasty popup that explains something went wrong with a plugin.

OpenCPPCoverage waiting for user input

Imagine this little piece of code:

std::string s; std::getline(std::cin, s);

All swell, you're OpenCPPCoverage is going to wait indefinitely for you to press a key. Which is something that will never, ever happen...

Currently, a timeout will eventually be hit which kills the process. That's bad, because it means you don't get a report.

Improvement - Debugging parameters

I create a new branch on my fork VS 2017 to add support of Debugging parameters

Moreover, I have some trouble with argv[0] which not contains application name: I fix some part.

Please review and add in main project if approved.

Fix strange WPF quirks in VS extension

The information doesn't always seem to update in the VS extension. Upon closer inspection it apprears something fishy is going on...

Relevant code: Coveragereport.xaml.cs, line 52-58

WCF should update lists in an ObservableCollection. While this works, apparently the DataGrid stops functioning when we use this. Using a normal List works seems to work, but doesn't update anymore.

Add support for VS 2017

Currently, published VSIX doesn't support VisualStudio 2017 Community.

Can you add it ?

Visual Studio 2022

I am firmly hooked on CPPCoverage. Are there any plans to create a version for VS2022?

Cobertura report on partition D

Hi,

CPPCoverage works fine if I create the report on a C partition. Unfortunately, it fails if I create a Cobertura report with sources on a D partition. Creation of the .cov file works fine AFAIK.

This problem is caused by the XML node “” within the Cobertura XML file. As it turns out, this is hardcoded in Coverage/FileCallbackInfo.h in line 269.

Suggestion: creating a new variable which stores the first character of the filenames and writing the variable in line 269 instead of the hardcoded “c”.

Best regards
Johannes

LoadSettingsFromStorage: FormatException: Input string was not in a correct format.

Hello,
I have a problem reading data into the GeneralOptionPageGrid class via the LoadSettingsFromStorage method. I am getting an error:

System.Exception: '255, 207, 184 is not a valid value for Int32.'
FormatException: Input string was not in a correct format.

The GeneralOptionPageGrid dialog box uses a CustomColorConverter object to write and read values of individual colors. When loading data (LoadSettingsFromStorage), the CustomColorConverter class uses the ConvertFrom method with CultureInfo set to CurrentCulture. Saving the data (SaveSettingsToStorage) is done by using the ConvertTo method with the CultureInfo set to InvariantCulture. These values affect how the color value is written and read. In my case, the CurrentCulture value is “en-PL” and the separator of the individual ARGB values is a semicolon. In the case of InvariantCulture, the separator is a comma.

The solution may be to write the data explicitly using CultureInfo.CurrentCulture:

index 69c0f71..583ff8a 100644
--- a/CoverageExt/GeneralOptionPageGrid.cs
+++ b/CoverageExt/GeneralOptionPageGrid.cs
@@ -2,6 +2,7 @@
 using System;
 using System.ComponentModel;
 using System.Drawing;
+using System.Globalization;
 
 namespace NubiloSoft.CoverageExt
 {
@@ -9,7 +10,12 @@ namespace NubiloSoft.CoverageExt
     /// Dumbfounded why we need this, since it effectievely shouldn't do anything else but even 
     /// using [TypeConverter(typeof(ColorConverter))] doesn't work.
     /// </summary>
-    class CustomColorConverter : ColorConverter { }
+    class CustomColorConverter : ColorConverter {
+        public override object ConvertTo( ITypeDescriptorContext context, CultureInfo culture, object value, Type destinationType )
+        {
+            return base.ConvertTo( context, CultureInfo.CurrentCulture, value, destinationType );
+        }
+    }
 
     [System.ComponentModel.DesignerCategory("")]
     public class GeneralOptionPageGrid : DialogPage
--

If this is an acceptable solution I can do PR. What could be other alternative solutions?

My Visual Studio version is 17.10.4.

Logging system

Integrate a proper logging system into the CPP code. We don't want ifdef's all over the place

Visual Studio 2010 / Windows 2003 server

Will this build under 2010?

GMock

Hello,

Thanks for share your great tool.

I have been using for a while with Visual Studio 2015 Professional without problem.

Recently I have added GMock (downloaded from trunk) to a small test project.

I can select "Run code coverage" without any problem if GMock is not used.
But if I use, for example EXPECT_CALL and select "Run code coverage", I get some output messages until Visual Studio crash.

Have you tested with GMock?

Thanks and best regards,
Jose.

Can't install on VS 2019

Can't install on Visual Studio 2019. Here is the log:

dd_VSIXInstaller_20190620132045_467c.log

Cannot write to c:\windows\system32\LastCoverageResults.log

Apparently OpenCPPCoverage writes to c:\windows\system32 by default, more specifically a file called LastCoverageResults.log . Not cool, since most users don't have access to that...

Simple workaround for now:

Create an empty file and call it LastCoverageResults.log .
Move it with admin rights to c:\windows\system32\
Since permissions are retained and the file is overwritten, you're good after this.

An easier way to exclude test code from code coverage

While #pragma works fine, it's not really convenient for excluding unit test code from the code coverage process. You basically end up writing that in every piece of code...

What we need is a simple way to exclude complete namespaces from the coverage tool. That way, our coverage results don't get messed up with all test code that isn't hit when everything works correctly...

This is absolutely non-trivial, because the application doesn't have knowledge of the coverage tool.

One way to do this is to create a special stub 'PassToCoverageTool' call, and intercept that using a breakpoint, thereby passing information to the coverage tooling. The implementation in the application should be a stub that's never inlined. Once that's implemented, we have a way of passing data to the coverage engine, which will help significantly with this issue.

It's tricky, it might just do the job...

Coverage report window is empty.

Here is my system configuration:

Windows: 10
Test library: GoogleTest(latest version)
VisualStudio: 2019 Community

And here is the steps to generate coverage report:

Right click on the project and run: "Run Tests"
Open a .cpp file.
Go to: Toos --> Coverage report.

It's empty!
Also i can't see any impact of CPPCoverage on my current file!

This is the output of CodeCoverage from the output window:

Calculating code coverage...
Loading process: D:\workspace\c++\cpp\projects\active\tdd_kata\build\windows\debug\x64\tdd_kata.exe... [Symbols loaded]
Loading: C:\Windows\System32\ntdll.dll...
[No symbols available: The request is not supported.]
Loading: C:\Windows\System32\kernel32.dll...
[No symbols available: The request is not supported.]
Loading: C:\Windows\System32\KernelBase.dll...
[No symbols available: The request is not supported.]
Patching IsDebuggerPresent() in KernelBase.dll
Running main() from D:\workspace\c++\cpp\projects\active\libs\googletest\googletest\src\gtest_main.cc
[==========] Running 8 tests from 3 test suites.
[----------] Global test environment set-up.
[----------] 6 tests from CalcStatTests
[ RUN ] CalcStatTests.ThrowStdInvalidArgumentWhenCallMinimumValueWithAnEmptyArray
[ OK ] CalcStatTests.ThrowStdInvalidArgumentWhenCallMinimumValueWithAnEmptyArray (0 ms)
[ RUN ] CalcStatTests.ReturnMinimumValueWhenPassAnArrayWithOneElement
[ OK ] CalcStatTests.ReturnMinimumValueWhenPassAnArrayWithOneElement (0 ms)
[ RUN ] CalcStatTests.ReturnMinimumValueWhenPassAnArrayWithTwoElements
[ OK ] CalcStatTests.ReturnMinimumValueWhenPassAnArrayWithTwoElements (0 ms)
[ RUN ] CalcStatTests.ReturnMinimumValueWhenPassAnArrayWithThreeElements
[ OK ] CalcStatTests.ReturnMinimumValueWhenPassAnArrayWithThreeElements (0 ms)
[ RUN ] CalcStatTests.ReturnMinimumValueWhenPassAnArrayWithEightElements
[ OK ] CalcStatTests.ReturnMinimumValueWhenPassAnArrayWithEightElements (0 ms)
[ RUN ] CalcStatTests.ThrowStdInvalidArgumentWhenCallMaximumValueWithAnEmptyArray
[ OK ] CalcStatTests.ThrowStdInvalidArgumentWhenCallMaximumValueWithAnEmptyArray (0 ms)
[----------] 6 tests from CalcStatTests (0 ms total)
[----------] 1 test from CheckoutTests
[ RUN ] CheckoutTests.CanCreateInstanceOfCheckoutClass
[ OK ] CheckoutTests.CanCreateInstanceOfCheckoutClass (0 ms)
[----------] 1 test from CheckoutTests (0 ms total)
[----------] 1 test from ManhatanDistanceTests
[ RUN ] ManhatanDistanceTests.CanCreateInstanceOfCheckoutClass
[ OK ] ManhatanDistanceTests.CanCreateInstanceOfCheckoutClass (0 ms)
[----------] 1 test from ManhatanDistanceTests (0 ms total)
[----------] Global test environment tear-down
[==========] 8 tests from 3 test suites ran. (1 ms total)
[ PASSED ] 8 tests.
Loading: C:\Windows\System32\kernel.appcore.dll...
[No symbols available: The request is not supported.]
Loading: C:\Windows\System32\msvcrt.dll...
[No symbols available: The request is not supported.]
Loading: C:\Windows\System32\rpcrt4.dll...
[No symbols available: The request is not supported.]
Process exited with code: 0.
Gathering profile data of 0 sources...
Filtering post-process notifications...
Writing coverage report...done.
Updating coverage results from: D:\workspace\c++\cpp\projects\active\tdd_kata\windows\CodeCoverage.cov

Issues with unloading DLL's

Let's say you load a DLL, execute some tests, unload it (and all dependencies), load another DLL, execute some tests, unload it (and all dependencies) and so forth...

Note that it seems to be pretty hard to reproduce this bug, unless your testing framework follows this pattern.

When using code coverage, this can give you trouble... and even though this is speculation, this appears to be the reason:

The code coverage runner collects stack traces using dbghelp, which are used for the profile information that's collected on-the-fly. However, it often happens that parts of the stack trace are not valid, for example when you're in a 'catch' of an exception. If the symbols are then looked up using dbghelp, it will attempt to read a piece of memory that's invalid - which triggers an error.

Now, if another DLL is loaded and then unloaded, memory might be valid while looking for a symbol. In other words, no invalid page exception will occur, and no error will be thrown. The result is that the coverage runner will just stand there, waiting for dbghelp to finish (which it probably never will)...

If you just test any single DLL, errors will be thrown as usual, and everything will work just fine.

There's an easy workaround: don't unload DLL's.

I'll keep this bug open for now for reference.

Generate Clover XML for integration in Bamboo

Atlassian has their own fileformat, which is very, very close to Cobertura... we should emit this so that Bamboo integration is possible.

Definition: http://stackoverflow.com/questions/30378099/where-can-i-get-an-xsd-that-defines-the-clover-xml-schema . Example: https://answers.atlassian.com/questions/68875/clover-xml-schema .

How can I run it under VS 2017?

Hi,

Extension doesn't load into Visual Studio, activity log says:

  <entry>
    <record>1774</record>
    <time>2019/11/14 11:14:22.082</time>
    <type>Error</type>
    <source>VisualStudio</source>
    <description>CreateInstance failed for package [CoverageExtPackage]Source: &apos;mscorlib&apos; Description: Could not load file or assembly &apos;Microsoft.VisualStudio.Shell.15.0, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a&apos; or one of its dependencies. The system cannot find the file specified.&#x000D;&#x000A;System.IO.FileNotFoundException: Could not load file or assembly &apos;Microsoft.VisualStudio.Shell.15.0, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a&apos; or one of its dependencies. The system cannot find the file specified.&#x000D;&#x000A;File name: &apos;Microsoft.VisualStudio.Shell.15.0, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a&apos;&#x000D;&#x000A;   at System.Reflection.RuntimeAssembly.GetType(RuntimeAssembly assembly, String name, Boolean throwOnError, Boolean ignoreCase, ObjectHandleOnStack type)&#x000D;&#x000A;   at System.Reflection.RuntimeAssembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase)&#x000D;&#x000A;   at System.Activator.CreateInstanceFromInternal(String assemblyFile, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence securityInfo)&#x000D;&#x000A;   at System.AppDomain.CreateInstanceFrom(String assemblyFile, String typeName)&#x000D;&#x000A;&#x000D;&#x000A;WRN: Assembly binding logging is turned OFF.&#x000D;&#x000A;To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.&#x000D;&#x000A;Note: There is some performance penalty associated with assembly bind failure logging.&#x000D;&#x000A;To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].&#x000D;&#x000A;</description>
    <guid>{3D61029D-1E2F-4471-93CA-18FDB2F50CD9}</guid>
    <hr>80004005 - E_FAIL</hr>
    <errorinfo></errorinfo>
  </entry>

What shuold I do, to run it? Do I need to install Visual Studio 2015?

Update documentation

The tool looks for a file named "CodeCoverage.xml" not "Coverage.xml" like the documentation says.

Should fix that... And add pictures, etc. so that people see what they will get.

History view

Information is currently for one (the latest) snapshot. We want history - and to be able to put that on git as well, so that we can let servers do the heavy lifting.

Changes involve:

Storing coverage files with a date/time.
Some date/time picker in Visual Studio.

Run coverage incrementally

If we integrate coverage with the tests, we can run tests incrementally. Basically it involves taking a test class, running coverage, storing that and iterating.

For a new run, we can simply check which code has been changed since the last report, check it with the previous report and only run the tests that have modified code.

Prerequisite: open source our test suite.

The 'CoverageExtPackage' package did not load correctly.

Hello, I'm experimenting an issue with the extention.

I'm using VS 2017:

I just followed the guide of installation and when I try to 'Run code coverage' I got the following message:

I tried reinstalling all my VS suit and the extention, but it as the same behavior.

Do I need to install other thing or may I missing anything?

Thanks!

15-minute delay for event

Currently the VS addin waits for 15 minutes of 'inactivity' before killing the process. Inactivity here is defined as no console output.

I guess we can do better here: if there hasn't been any CPU or console activity in a minute, it's fair to say that we can kill the process. Who wants to wait for a unit test like that?

Stupid little if-then-else quirks

Say you have something like:
if (x) {
return;
} else { // *1
// some code
return;
} // *2

Well, apparently it's compiled in Visual studio as follows:

[conditional branch to Y]
[return]
[unconditional branch to Z] // *3
[label Y]
[... some code]
[return]
[label Z]
[return] // *4
-- end of method

And guess what... *3 actually generates a breakpoint on *1 and *4 generates a breakpoint on *2. End result: the unconditional branch to Z actually ends up as 'non-covered' at *1 and the label Z might end up as 'non-covered' at *2.

So, your code coverage is less-then-optimal, even though you did your very best to cover everything. And that means our tool doesn't give you the warm feeling you deserve.

How are we going to fix this?

Recognizing *3 is relatively easy, because the unconditional branch happens just after a return.
Recognizing *4 is relatively painful, because the return happens after a return (and therefore a lot of stack processing instructions are in between).

Luckily, *3 happens way more often than *4. Let's focus on that one...

Build server and absolute path

Hi,

I have setup in command line CppCoverage.exe which is run by my build server (in this case TeamCity).
I put in artifact my *.cov to see result. BUT I can copy/paste into my dev environment (near my *.sln) because the filepath into cov are in absolute (C:\MY_BUILD_SERVER\MY_BRANCH\mySolution\mySource.cpp).

May be, a solution is give relative path for code into solution (enable by command line).
Finally, you can share the coverage file to build server or other dev without care abort when code/solution is.

I will try something in my fork and will reply if I find solution.

Performance overview panel

Performance overview panel is currently not available. Could also integrate that in coverage panel.

TODO: Decide what's best and implement.

Check default path of x86 opencppcoderage

The tools expects opencoverage to have this path: "C:\Program Files (x86)\OpenCppCoverage\x86\OpenCppCoverage.exe". The default install path is actually "C:\Program Files (x86)\OpenCppCoverage\OpenCppCoverage.exe"

Actually the latter has been implemented to be a fallback. At least, that's what I thought I did. Should check and perhaps fix that.

I can't load the generated Cobertura XML file

I am using a different test framework (cmocka). I can generate the Coverage.xml file, I copy it the solution folder. How do I view it within visual studio?
"If you don't use MSTest, you can still use the Cobertura XML file generated by OpenCPPCoverage as "Coverage.xml" to the solution folder."

Thanks,
Philip

VS 2019 Issue

installed the plugin.
ran my unit tests
right clicked on the unit test project and clicked 'Run code coverage' and nothing happened
closed all tab and reopened code file the was being tested and coverage info
checked coverage report window and no info
closed vs2019 and reopened to try process again and found 'Run code coverage' context menu
item is now missing

this is a c# project built with netcore 3.0 with the latest vs release

Tool not visible on VS 2013 Pro

Hi,

I cannot find the tool after installing the extension in VS 2013 Pro. It is in the list of installed extension, but I see it nowhere else.

The "Run code coverage" context button does not appear, even on a project compiled in DEBUG mode.

"Tools->Coverage Report" does not appear

Maybe I did something wrong. Is VS 2013 still supported?

Would this work with Node.js native modules?

In Node.js JavaScript, when one wants to link to native code, there are many build tools that compile C/C++ into native .node binaries that are imported/required by the Node.js JavaScript runtime.

I've been using GCC to compile projects with gcov enabled to get great coverage reports for Linux and macOS hosts. However Windows hosts are proving to be more reticent with MSBuild.exe doing the compilation.

serialport/node-serialport#2314

I've been searching for a project that might help us generate coverage reports for Windows binaries. That this package has a free CLI tool gives me hope that integrating would be possible.

Looking into it more, it seems this tool is targeting being run as a Visual Studio extension, which I imagine gives easier GUI instructions on configuration. In our Node.js environment, node-gyp (a fork of Chrome's defunct build tool GYP) uses a file binding.gyp to descript required build flags and variations for alternate platforms. It looks like I'll need to try running Coverage-x64.exe in binding.gyp on Windows hosts, but I'm not seeing a 100% clear example of the commands needed to properly use this CLI tool.

I'm going to poke at this myself some more but I thought asking here early might save me some trouble.

Cheers.

[Enhancement proposal] Add support to delete coverage report from VS

Hi,
Thank you for your work, it is a very useful and easy to use extension !
I would like to suggest you a minor improvement : to add a menu button to be able to delete the Coverage file from Visual Studio. Indeed once codecoverage is run and analysed, we may want to remove all the colours and reports. It seems the only way is to modify the code or to delete manually the coverage report file. I think it will be very nice if we could do it right from the menu bar in VS.
Thanks again !
Malick