Analyzing Code Churn and Code Coverage Using the Code Churn and Run Coverage Perspectives

You can report on the software quality by using the Code Churn and Run Coverage perspectives from the SQL Server Analysis Services cube for Visual Studio Team Foundation Server. By using these perspectives, you can view just the measures, dimensions, and attributes that are associated with the changes in lines of codes and the extent to which code is covered in builds and test runs.

These perspectives are based on the relational tables that you can use to report on code changes and coverage as a property of the build, the build assembly or platform, the test run, or the changeset. For more information, see Code Churn Tables and Run Coverage Tables.

By using the Code Churn perspective, you can create reports that answer the following questions: How many files with a specific file name extension changed in a particular build? How many lines of code are in the source base for a particular build? Which changesets have been submitted, and what are the details of each change? (For example, who made the change, which files were changed, and on what date was the change made)?

By using the Run Coverage perspective, you can create reports that answer the following questions: Which assemblies have the least test coverage? Which test runs cover the most code? Which architectures or build types have the most test coverage? Note If your data warehouse for Visual Studio Application Lifecycle Management (ALM) is using SQL Server Enterprise Edition, the list of cubes will include Team System and a set of perspectives. The perspectives provide a focused view of the data so that you do not have to scroll through all of the dimensions and measure groups in the whole Team System cube.

In this topic

• Example: Code Churn Report

• Code Churn Measures

• Run Coverage Measures

• Dimensions and Attributes in the Code Churn Perspective That Support Filtering, and Categorization

• Dimensions and Attributes in the Run Coverage Perspective That Support Filtering and Categorization

• Required Activities for Managing Builds and Tests

Example: Code Churn Report

By using a PivotChart report in Excel, you can create a trend report that displays the code churn over time, similar to the report that the following illustration shows.

The process templates for Microsoft Solutions Framework (MSF) v5.0 automatically provide the Code Churn report in Excel. For more information, see Code Churn Excel Report.

Back to top

Selecting and Filtering Pivot Fields

You can create a code churn report by performing the following steps:

1. In Excel, connect to the SQL Server Analysis Services cube for Visual Studio Team Foundation Server, and insert a PivotChart report.

   For more information, see Create a Report in Microsoft Excel for Visual Studio ALM.

2. Right-click the chart, click Change Chart Type, click Area, and then click Stacked Area.

3. For each report filter, right-click each of the following fields, specify the hierarchies, weeks, or other elements of interest, and then drag the field to the Report Filter area.

   • Team Project Hierarchy from the Team Project dimension

   • Work Item.Iteration Hierarchy from the Work Item dimension

   • Work Item.Area Hierarchy from the Work Item dimension

   • Year Week Date from the Date dimension

4. In the Date dimension, expand More fields, and drag the Date, Week, or Month fields to the Axis Fields (Categories) area based on how granular a report you want to generate.

5. Drag the Lines Added, Lines Modified, and Lines Deleted fields from the Code Churn measure group to the Values area. You must drag each field separately.

Back to top

Code Churn Measures

Code churn measures quantify how much change is occurring in your project. In general, high levels of churn indicate project instability. You should expect high rates of churn at the start of a product cycle or after the team has implemented many changes. Toward the end of an iteration or before a release, you should expect the level of churn to decrease, which indicates that your project is more stable.

The following table describes the measures in the Code Churn measure group. By using these measures, you can create reports that show how many file versions are stored in Team Foundation version control and how much the code has changed. You can analyze metrics by file directory, build, or team member who checked in changes, and you can determine how those metrics change over time.

For information about similar metrics that you can collect for builds, see Analyzing Build Details and Build Coverage Using the Build Perspective.

Measure	Description
Code Churn Count	The number of times that the team changed files in version control.
Lines Added	The number of lines of code that the team added to files for the dimensions that you specify.
Lines Deleted	The number of lines of code that the team deleted from files for the dimensions that you specify.
Lines Modified	The number of lines of code that the team modified during the time period that you specify.
Total Churn	Churn in the code, computed as: [Lines Added] + [Lines Deleted] + [Lines Modified].
Total Lines	The number of lines in the part of the file path hierarchy that you specify. You must also specify one or more builds to indicate the point or points at which to perform this calculation. If you do not specify one or more builds, NULL is returned. The number of lines is calculated by aggregating the lines added and lines deleted that have contributed to a specific combination of build type and operating system. Tip The Total Lines measure can cause the OLAP query to timeout. If your report takes too long to render, consider shortening the changeset, build, test run, or date range.

Back to top

Run Coverage Measures

The following table describes the measures in the Run Coverage measure group. By using these measures, you can create reports that show the extent to which the code was covered by tests in a test run. For information about similar metrics that you can collect for builds, see Analyzing Build Details and Build Coverage Using the Build Perspective.

Back to top

Dimension and Attributes in the Code Churn Perspective That Support Filtering and Categorization

The following table describes the dimensions and attributes in the Code Churn perspective. These attributes supplement the Team Project and Date shared dimensions, which Working with Shared Dimensions describes. You can aggregate the measures along each of these attributes.

Back to top

Dimensions and Attributes in the Run Coverage Perspective That Support Filtering and Categorization

The following table describes the dimensions and attributes in the Run Coverage perspective. These attributes supplement the Team Project and Date shared dimensions that Working with Shared Dimensions describes later in this topic. You can aggregate the measures along each of these attributes.

Back to top

Required Activities for Managing Builds and Tests

To create build reports that contain useful data, team members must perform the following activities to manage builds and tests:

• Configure a build system. To use Team Foundation Build, the team must set up a build system.

  For more information, see Configure Your Build System.

• Create build definitions. The team must create at least one build definition. The team can create several definitions, each of which can be run to produce code for a different platform or a different configuration.

  For more information, see Create a Basic Build Definition.

• (Recommended) Run builds regularly. The team can automatically run builds at intervals that they specify or after every check-in. By using the schedule trigger, the team can automatically run builds at the same time or times on the same day or days that they specify. For more information, see Specify Build Triggers and Reasons and Run and Monitor Builds.

• (Optional) Define tests to run automatically as part of the build. As part of the build definition, the team can define automated tests to run as part of the build and analyze the impact of code changes on the tests.

  For more information, see Use Your Build System to Work with Tests.

• Configure tests to gather code coverage data. For code coverage data to appear in the report, team members must instrument tests to gather that data.

  Important

  To collect data about code coverage, the team must have installed Visual Studio Premium or Visual Studio Ultimate on the machine with the build agent. For more information, see Create and Work with Build Agents.

  For more information, see How to: Configure Code Coverage Using Test Settings for Automated Tests and How to: Gather Code-Coverage Data with Generic Tests.

• Publish tests. As part of the build and test activities, the test team must publish test results to the data store for Team Foundation Server.

  For more information, see Team Foundation Build Activities and Command-Line Options for Publishing Test Results.

Back to top

See Also

Concepts

Code Churn Tables

Run Coverage Tables

Perspectives and Measure Groups Provided in the Analysis Services Cube for Team System

Other Resources

Use Your Build System to Work with Tests

Change History