Code coverage during TFS 2012 build

A common question about TFS 2012 build is: how can I ask for code coverage?

The answer is really simple, you should go to the test section of build definition and change the run settings from Default to another setting that includes code coverage and this is really everything you need to do.

Figure 1: Change run settings to enable code coverage

Now launch the build and verify that you have your binaries instrumented and Code Coverage correctly computed.

Usually this lead to another question: Can I decide which assembly to include in code coverage instead of having all of them instrumented?

The solution to this answer is creating a customized test run setting file , the only drawback is that you have no template inside Visual Studio and no editor (as you had in VS 2010 with TestSettings files). The good news is that you can simply add an xml file inside your solution, give to it the extension.runsettings and copy inside it this simple fragment of configuration.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

<?xml version="1.0" encoding="utf-8"?>
<!-- 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>
            <!-- Match assembly file paths: -->
            <ModulePaths>
              <Include>
                <ModulePath>.*fabrikamfiber.web.dll$</ModulePath>
              </Include>

            </ModulePaths>

            <!-- We recommend you do not change the following values: -->
            <UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
            <AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
            <CollectFromChildProcesses>True</CollectFromChildProcesses>
            <CollectAspDotNet>False</CollectAspDotNet>

          </CodeCoverage>
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

You have lots of options, but in this example I’m interested only in limiting the number of assemblies that will be instrumented for Code Coverage. This can be done simply specifying one or more regular expression in the ModulePaths section. You can use Include to define regex for inclusion, or you can use exclude to specify which assemblies will be excluded.

Once you authored this file, you should use it as active test setting configuration to test if everything is good , and verify that after running all of your test locally, Code Coverage result is what you expected. Remember that once you’ve have this run settings activated, it will be used for all of your local test run.

Once everything is ok you need to store this file in source control, check-in and modify Build configuration to use this customized file as a Run Settings File for the build and the game is done.

Now fire the build again, this time only selected assemblies will be used for code coverage.

MSDN Link to test run setting file: Customizing Code Coverage Analysis

Gian Maria.