I am following article for code coverage in VS 2013 http://msdn.microsoft.com/en-us/library/dd537628.aspx. It shows coverage of Test and not actual code.
I have selected unit test from Test explorer and click on Analyze Code Coverage -> Selected Test. Code coverage window is opened up at the bottom and It shows dll of unit test and its coverage and actual dll with code coverage is not shown.
Also, I looked into article http://msdn.microsoft.com/library/jj159523.aspx. Copied pdbs and dll into same location. In the code coverage window message was
Empty results generated: No binaries were instrumented. Make sure the tests ran, required binaries were loaded, had matching symbol files, and were not excluded through custom settings. For more information see http://go.microsoft.com/fwlink/?LinkID=253731"
Any idea about this?
I have tried steps given in the link.
http://blogs.msdn.com/b/allendm/archive/2012/09/08/empty-coverage-file-with-profiler-related-errors-in-the-event-logs.aspx
Slight change if you are using VS 2013.
a) Environment variable VS120COMNTOOLS is set to \common7\tools
b) Regkey HKLM\SOFTWARE\Microsoft\VisualStudio\12.0\InstallDir is set to your \Common7\IDE\
c) covrun32.dll and covrun64.dll exist in "\Team Tools\Dynamic Code Coverage"
Removed VS110COMNTOOLS environment variable. These changes worked for me.
I was able to resolve my issue. The reason why code coverage was not happening on my production DLL was: reason = "has_fixed_base". Once I changed this setting to: Yes (/DYNAMICBASE), the coverage started working.
It would help to check these steps:
Open Project Properties
go to Linker->Advanced page
In that, check Randomized Base Address
Change it to Yes (/DYNAMICBASE)
This should start code coverage.
Related
I'm using VS Code for a Go project. I have it configured to show the code coverage with gutter markings after I run the tests.
The issue I'm having is that if I make any changes to a file in the package, and then save it, VS Code then removes all of the coverage markings from all package files. I've gone through all of the Go settings and cannot find one that prevents this from happening.
There are options to re-run the tests on every save, which would then show the new coverage markings, but that's not feasible for this package because the tests take relatively long to run.
I'd like to find a way for it to keep the most recent test coverage markings when I save a file, instead of removing them all. Is this possible?
Recently I migrated all my C# projects from VS2010 to VS2013. There were barely any code changes required but immediately after I checked in the projects, I noticed that CI started failing. On checking the issue, I realized that the coverage file generated after running unit tests was not being generated in the location specified in the .testsettings file. In the Test Results Names section of Test Settings in VS2010, I configured a user defined naming scheme and unchecked the Append date-time stamp checkbox. This would generate the coverage file in \\data.coverage. After migrating to VS2013, the coverage file is getting generated in a Test Settings folder which believe is the default location when the Default naming scheme is chosen.
On researching a bit, I found an MSDN post and a few other blogs posts suggesting doing away with the .testsettings file and adopting the new .runsettings file. The weird thing is Microsoft is recommending usage of the .runsettings file but don't seem to deliver a default one which I can build upon. In any case, I did create one based on the sample provided on the same MSDN post. It did work for me as far as creation of the coverage file is concerned but I again faced the same problem that it is getting generated in a Test Results folder. The bigger problem is that a sub-folder with some GUID type name is created into which the coverage file is dumped and it changes every time a test is run with code coverage ON.
I wonder if there's a way make my VS2010 settings work as expected in VS2013 or using the .runsettings file, can I provide the complete path where the coverage file should be created?
Go to Test->Test Settings->Select Test Settings File and select the .testsettings file associated with your test project. It's a hack but always works.
Is it possible somehow to sort assembly names by name or by % of covered blocks in the code coverage results on the build's Summary view?
It is hard to find specific assembly without sorting when we have 100+ assemblies in the instrumented binaries list.
I tried to sort all assemblies in the "servertestrun.testrunconfig" file used for MSTest (All assemblies under Regular tag), but it was not helpful.
You can sort the assemblies in the code coverage window. For that, you should do the following steps.
Click "View Test Results" in the build summary which will open the results file in test result window.
In test results window there is a gesture to show the code coverage results.
In code coverage window, you can sort the assemblies and can view full details of code coverage.
I've written a program that tells me whether all the dlls in a code coverage result file are above a specified code coverage percentage.
It works great except when a dll has 0% code coverage, because dlls with 0% code coverage aren't included in the visual studio code coverage result file at all.
I have access to a list of the dlls that were instrumented for this code coverage run, but I'd much rather just look at the code coverage file if I can.
Is there some way to get Visual Studio to add the code coverage results for dlls where the code coverage percentage = 0%?
Full disclosure: I am on the team that develops this feature.
Unfortunately, this information is not present in the code coverage file. When a binary is instrumented, we insert special probes to tell us that it exists and to detect when each code block is executed.
We do not save the list of DLLs in the target process, so we only know about instrumented DLLs that get executed (just being instrumented is not enough).
The easiest workaround is what you mentioned in your question.
Thanks for your feedback, though, we will take it into consideration. Sorry for the difficulty here.
The trick we're using is to add one Test Project with a special Test which calls a special public static method in every assembly that does nothing more than return true. That way the assembly is hit at least once and the one liner doesn't really impact the total coverage data.
I've used Reflection to do this in some projects, and now we're just adding the CodeCoverageTest project to every solution and the CodeCoverage.Ensure() method in every Assembly.
I am forcing myself to learn test-driven development, and so far I'm enjoying myself. There's a few quirks that Visual Studio Unit Testing has that is driving me batty though. A bit of background information, my project folder looks like this:
[Root] BitFlex
BitFlex\Code
BitFlex\Debug
BitFlex\Documents
BitFlex\Release
Now of course all the source code is stored in the code folder, and on a build the project output either goes to the debug or release folders depending on the current configuration. Now for my unit testing, I have it setup so the test project is output to either:
BitFlex\Debug\Unit Tests\
BitFlex\Release\Unit Tests\
1) At this point, everything is fine and dandy. There are two problems with this, the first being that when I run a test it cannot find the assembly, as it gives me this error:
Error AssignDefaultProgramTest BitFlex.UnitTests The test assembly 'D:\src\DCOM Productions\BitFlex\Code\TestResults\David Anderson_DCOMPRODUCTIONS 2009-07-31 23_21_00\Out\BitFlex.UnitTests.dll' cannot be loaded. Error details: Could not find file 'D:\src\DCOM Productions\BitFlex\Code\TestResults\David Anderson_DCOMPRODUCTIONS 2009-07-31 23_21_00\Out\BitFlex.UnitTests.dll'.
I cannot seem to find information on this error, or how to resolve it so I suppose that's where everyone's experise around here comes in to play.
2) My other beef is that Visual Studio generates the "Test Results" folder in my code directory, I would prefer to move that to my Unit tests folder in either output configuration. Is there a way to do this, or a better practice to setting up a well organized Unit Test using my folder hierarchy?
By default MSTesting framework runs all tests in an 'isolated' location and not from the binaries directory.
To fix this you can do one of these two:
1. go to the test configuration file and under deployment uncheck deploy the tests.
2. don't use path when looking for external files instead use deploy attribute or the test config to deploy the needed files along with your tests.
For doing TDD with MSTest, turn off deployment. You shouldn't need it for "unit testing."
Also, never ever EVER have VS automatically generate tests for you. What's generated may be fine for some types of functional testing, but are usually very poor unit tests.