Excluding Generated Code from Azure DevOps Code Coverage
We have recently started setting up quality gates in our projects that have their CI/CD pipelines in Azure DevOps. More specifically, we don't want to let any commits in that would decrease our code coverage in these solutions.
We have created our baselines, and noticed that the WCF clients that Visual Studio Generates are included in the coverage for some odd reason. We have double-checked that they do have the GeneratedCodeAttribute applied to all of the classes, so we were sort of baffled about why the code coverage tool would not exclude them based on that.
We did not have a hand-made runsettings file, so our first go-to was that. Microsoft has a handy guide on creating them (well, two guides, to be honest), the first one we have found was a generic one about configuring unit tests with runsettings, that describes some runsettings file parameters, but the second result was much more specific, it was explicitly about customizing Code Coverage Analysis, and that did include some very specific pointers, including some examples, which we have truncated to our minimal usable version, something along these lines:
CodeCoverage.runsettings
A sensible question was "where on Earth should we place this file", and our gut feeling was "wherever our .editorconfig and our .ruleset files are", and that was the solution root. We did some Google-fu, and soon felt our answer validated by the people of the internet.
This does include the GeneratedCodeAttribute in its inclusion criteria, and after setting it up in Visual Studio Test Explorer, our coverage did in fact exclude the generated WCF service client code.
After that win, all we had to do is telling Azure DevOps to do the same on our build agents as well.
The VSTest task, fortunately, has a Settings File field in its Execution Options region, so hooking it up with Azure was also a simple task. And so the generated classes were no longer reported as uncovered, and we did feast upon the lambs and sloths and carp and anchovies and orangutans and breakfast cereals and fruit bats and, well, I guess you get the point.
We have created our baselines, and noticed that the WCF clients that Visual Studio Generates are included in the coverage for some odd reason. We have double-checked that they do have the GeneratedCodeAttribute applied to all of the classes, so we were sort of baffled about why the code coverage tool would not exclude them based on that.
We did not have a hand-made runsettings file, so our first go-to was that. Microsoft has a handy guide on creating them (well, two guides, to be honest), the first one we have found was a generic one about configuring unit tests with runsettings, that describes some runsettings file parameters, but the second result was much more specific, it was explicitly about customizing Code Coverage Analysis, and that did include some very specific pointers, including some examples, which we have truncated to our minimal usable version, something along these lines:
CodeCoverage.runsettings
<!-- File name extension must be .runsettings -->
<RunSettings>
<DataCollectionRunSettings>
<DataCollectors>
<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Configuration>
<CodeCoverage>
<Attributes>
<Exclude>
<Attribute>^System\.Diagnostics\.DebuggerHiddenAttribute$</Attribute>
<Attribute>^System\.Diagnostics\.DebuggerNonUserCodeAttribute$</Attribute><Attribute>^System\.CodeDom\.Compiler\.GeneratedCodeAttribute$</Attribute><Attribute>^System\.Diagnostics\.CodeAnalysis\.ExcludeFromCodeCoverageAttribute$</Attribute>
</Exclude>
</Attributes>
<UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
<AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
<CollectFromChildProcesses>True</CollectFromChildProcesses>
<CollectAspDotNet>False</CollectAspDotNet>
</CodeCoverage>
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
</RunSettings>
This does include the GeneratedCodeAttribute in its inclusion criteria, and after setting it up in Visual Studio Test Explorer, our coverage did in fact exclude the generated WCF service client code.
After that win, all we had to do is telling Azure DevOps to do the same on our build agents as well.
The VSTest task, fortunately, has a Settings File field in its Execution Options region, so hooking it up with Azure was also a simple task. And so the generated classes were no longer reported as uncovered, and we did feast upon the lambs and sloths and carp and anchovies and orangutans and breakfast cereals and fruit bats and, well, I guess you get the point.
Comments
Post a Comment