Working with Merged Code Coverage Data
As described in How to: Merge Code Coverage Data, you can merge the code coverage data obtained through multiple test runs, or from multiple testers. You can also save the result of merging code coverage data, and re-import it. The following sections describe aspects of working with code coverage data.
The Limitations of Merging Test Results
The following list highlights the most common limitations you might encounter when you merge and import Coverage Data:
Importing XML data - If you import Code Coverage data from an XML file you can only see statistics for line coverage, not block coverage. For more information, see Exporting and Importing Merged Test Results.
Merging data from test runs - If you merge test results that include ASP.NET test runs, the Code Coverage Results window will display the data for ASP.NET artifacts in a separate node that contains a separate calculation. For more information, see Merging Data from ASP.NET Test Results.
Recompiling code between test runs - If you recompile your production code in between test runs and then try to merge those results, the merge might fail. For more information, see Importing Code Coverage Data Files.
Exporting and Importing Merged Test Results
After you have merged test results, you can save the results of the merge operation by exporting it as an XML file. For more information about exporting, see How to: Export Test Results.
This XML file contains all the merged code coverage data, which you can see if you re-import the file. This includes statistics on lines of code and statistics on blocks of code.
Note
You can configure the columns of the Code Coverage window to display different data about lines and blocks of code, such as the percentage of lines of code that were covered, that were not covered, and that were partially covered during testing.
However, if you re-import this XML file and then merge it with additional code coverage data, only the statistics on line coverage are retained, not the statistics on block coverage.
Merging Data from ASP.NET Test Results
You can merge results that include one or more ASP.NET test runs, but the Code Coverage Results window displays ASP.NET data under Merged Results in distinct nodes, rather than in a single, merged node. That is, although it displays data from all selected test runs including runs that include ASP.NET tests, it performs no statistical calculations to merge ASP.NET code coverage data. This means that it displays data for ASP.NET tests in a separate node for each test run, not merged together under one node.
This limitation applies only to ASP.NET artifacts. During ASP.NET test runs, code coverage data can be gathered when other binary files are tested, including DLLs that your ASP.NET project references and assemblies that have been added to your ASP.NET project. In these cases, the code coverage data for a particular binary file is displayed in a single, merged node under Merged Results.
Importing Code Coverage Data Files
When code coverage data is collected, it is stored in its native format in a file that has the extension .coverage. When you view code coverage data after a test run, Visual Studio displays it by opening the resultant .coverage file. Also, Visual Studio is associated with the .coverage file name extension, which means that if you double-click such a file in Windows Explorer, the file opens automatically in Visual Studio.
Test result data, including code coverage data, is stored in XML format only when you explicitly export it. The only reason to export code coverage data as an XML file is to save the results of merging multiple code-coverage results.
You can import a .coverage file, by using the Import button on the Code Coverage Results window toolbar. If you do this, note the following:
To open a .coverage file, Visual Studio must be able to find on disk the instrumented assemblies and their program debug database files, which have the extension .pdb.
When importing this file type, Visual Studio searches the directory that contains the .coverage file and the directory that contained the assemblies when they were tested. To do this, Visual Studio uses the _NT_SYMBOL_PATH and VSCOVER_BINPATH variables. If the _NT_SYMBOL_PATH variable is set to the directory that contains symbols and VSCOVER_BINPATH to the directory that contains the assemblies, Visual Studio can find the files and open the .coverage file. But if Visual Studio cannot find either the symbols or the assemblies in any of the paths mentioned, the .coverage file cannot be opened. Knowing the importance of these paths and variable settings helps you if you try to import a .coverage file directly.
XML files that contain test results do not exhibit this behavior. The XML file is self-contained and does not require that assemblies or .pdb files also be opened.
If you import multiple .coverage files, you will be able to see statistics in both blocks and lines. If, however, you import code coverage data in both files formats that is, .coverage and XML, you will see statistics only on line coverage, not block converge.
See Also
Tasks
How to: Obtain Code Coverage Data