How to: Collect Data to Check Which Tests Should be Run After Code Changes

By using test impact analysis, you can identify the tests that you should run, based on coding changes that were made to the application that you are testing between builds.

When you use test impact analysis with Microsoft Test Manager, you are required to use Team Foundation Build to build your application and Team Foundation version control for your source code for the application being tested. Test impact information is gathered only on tests with a status of passed. It is not collected when you file a bug or when a test that is marked as failed is complete.

The requirement for using Team Foundation Build is only applicable to collecting data from Microsoft Test Manager, as the test plan must be associated with a build produced by Team Foundation Build for the test impact analysis feature to work properly. To use the Test Impact View in Microsoft Visual Studio 2010, you do not need to use Team Foundation Build and the solution does not have to be under any source code control system.

Warning

Test impact analysis works by instrumenting managed assemblies that are loaded into a process at runtime. This must be done after the first test for the run is started. If the process that you want to monitor has already started, no logs will be gathered because the process is already running. To circumvent this, either make sure that the process is stopped before you start your first test, or restart the process after the test has begun.

For more information about collecting test impact analysis data, see Recommending Tests to Run That are Affected by Code Changes.

You can configure the diagnostic data adapter for test impact analysis from Microsoft Test Manager and Microsoft Visual Studio 2010. Test settings can be configured to use the diagnostic data adapter for test impact analysis to monitor specific processes and modules for changes that affect existing tests.

The following illustration shows how to configure the diagnostic data adapter using Microsoft Test Manager.

Configure Test Impact Analysis

The following procedure describes how to configure test impact analysis from the configuration editor. These steps apply to both the configuration editor in Microsoft Test Manager and Microsoft Visual Studio 2010.

Note

Test impact analysis can be used with either manual or automated tests.

Configure Test Impact Analysis for your Test Settings

Before you perform the steps in this procedure, you must open your test settings from either Microsoft Test Manager or Microsoft Visual Studio 2010, and then select the Data and Diagnostics page.

To configure test impact analysis for your test settings

  1. Select the role to use to collect test impact analysis data.

  2. Select Test Impact.

  3. If you are collecting test impact data for a Web client role, you must also select ASP.NET Client Proxy for IntelliTrace and Test Impact.

    This proxy enables you to collect information about the http calls from a client to a Web server for the IntelliTrace and Test Impact diagnostic data adapters.

  4. Click Configure for Test Impact.

    The dialog box to configure test impact analysis is displayed.

  5. Click the Processes tab. The process list determines whether collection should occur for whole processes. This option lets you include all the processes that are running on the system except the processes that you specify.

  6. Select either Collect data from all processes except for the following and use Add to add to the list of processes and Remove button to remove a process.

    -or-

    Select Collect data from specified processes only and use Add to add to the list of processes and Remove button to remove a process. This option lets you specify exactly which processes you want.

  7. Click the Modules tab. The module list determines whether or not collection should take place for an individual module that is loaded into a process which you are collecting data from.

  8. Select either Collect data from all modules except for the following and use Add to add to the list of modules or click Remove to remove a module. This option lets you include or exclude modules loaded into the processes that are configured for test impact data collection.

    -or-

    Select Collect data from only the following modules and use Add to add to the list of modules and Remove button to remove a module. This option lets you specify exactly which modules you want.

    Note

    By default, both the process and modules list exclude all Microsoft assemblies. If you want to change these settings, you can empty the lists, change the setting to be an "include" list rather than an "exclude" list, and manually specify the individual assemblies that you want data collected from.

  9. Click the Advanced tab. If you want to collect data from ASP.NET applications that are running on Internet Information Services on your local machine, select Collect data from ASP.NET applications running on Internet Information Services.

    Note

    If you want to collect data from ASP.NET applications that are running on Internet Information Services on remote client machines, you must also use the ASP.NET Client Proxy for IntelliTrace and Test Impact data and diagnostic adapter. For more information, see Setting Up Machines and Collecting Diagnostic Information Using Test Settings.

  10. If you are using Microsoft Test Manager, click Save. If you are using Visual Studio, click OK. The diagnostic trace collector settings are now configured and saved for the test setting.

    Note

    To reset the configuration for this diagnostic data adapter, click Reset to default configuration for Visual Studio and Reset to default for Microsoft Test Manager.

See Also

Tasks

Create Test Settings for Manual Tests

Create Test Settings for Automated Tests as Part of a Test Plan

Create Test Settings to Run Automated Tests from Visual Studio

How to: Configure ASP.NET Profiler for Load Tests Using Test Settings

Concepts

Setting Up Machines and Collecting Diagnostic Information Using Test Settings

Running Manual Tests Using Test Runner

Recording and Playing Back Manual Tests