Test Impact Analysis in Visual Studio 2010
Depending on the size of your code base, running unit tests every time a code change is made can be a daunting process. Test Impact Analysis in Visual Studio 2010 (Premium and Ultimate Editions) can speed up that process.
Depending on the size of your code base, running all your unit tests every time a code change is made can be a daunting and time-consuming process. Visual Studio 2010 (Premium and Ultimate Editions) provides a new tool called Test Impact Analysis to help speed up that process.
Test Impact Analysis analyzes the changes made to the code base, and determines what unit tests may be affected, or "impacted," by the code change. It then provides the developer with a list of impacted tests. The developer has the option at that point to run only the impacted tests, in effect testing just the code changes that were made, or running all the unit tests in the solution to perform full regression testing. Providing the developer a way to only run the tests affected by the code change can help to speed up the development process.
Test Impact Analysis can be part of a developer's testing process when they are building their application locally (i.e., hitting F5), and can also be incorporated into Team Foundation Build and Microsoft Test and Lab Management. One caveat to keep in mind is that Test Impact Analysis currently only supports managed code.
To show a simple example of Test Impact Analysis, let's create a simple C# class with three methods (Figure 1). For each method, create a unit test for testing the method.
[Click on image for larger view.]
To see information around Test Impact Analysis, we need to open the Test Impact View window. To do that, select Test | Windows | Test Impact View from with Visual Studio 2010. Figure 2 shows the initial window.
Currently Test Impact Analysis is not enabled, so there is no data available on impacted tests. To enable this feature, either click the enable link listed in the window, or go to the Test Settings in Visual Studio and enable the Test Impact diagnostic. Test Impact Analysis is an example of a feature in Visual Studio 2010 called diagnostic data adapters. Diagnostic data adapters allow data to be captured while tests are executing. Other examples of diagnostic data adapters include Intellitrace and code coverage.
Once Test Impact Analysis has been enabled, the Test Impact View window will change, as shown in Figure 3.
Visual Studio needs to gather information on your code base and the tests in it, to create a baseline, before Test Impact Analysis can begin to work. To generate that baseline, rebuild the solution, and then rerun all the unit tests. Once that is done, the Test Impact View window will change as in Figure 4.
Now let's see Test Impact Analysis in action. I'm going to make changes to two of the methods in my test class, to intentionally break them. Then I'll right click on my solution in Solution Explorer and select Build to rebuild my application.
After the application has been built, Test Impact Analysis analyzes the resulting assemblies to look for meaningful changes to method instructions or data, and determines what unit tests may be impacted as a result of the code changes. As you can see in Figure 5, the Test Impact View is showing that I have impacted two unit tests as the result of my code changes.
If I want to see what code changes caused the test to be impacted, I can select a test in the Test Impact Window. In the Code Changes pane, it will show the method that contains the changed code.
If I want to only run the impacted tests, I can click the Run All Impacted Tests button in the Test Impact View window toolbar. As shown in Figure 6, the two impacted tests have run, and for this scenario, have both failed.
If we go back to the Test Impact View window, we will see that the two tests are still listed as impacted. They will continue to be listed as impacted until they are run and complete successfully.
While this column only shows a small test example, one can easily see how Test Impact Analysis could be used to speed up the development of a large project. Time can be saved by only running impacted tests as code is changed, and running the full suite of tests for regression purposes.
About the Author
Mickey Gousset spends his days as a principal consultant for Infront Consulting Group. Gousset is lead author of "Professional Application Lifecycle Management with Visual Studio 2012" (Wrox, 2012) and frequents the speaker circuit singing the praises of ALM and DevOps. He also blogs at ALM Rocks!. Gousset is one of the original Team System/ALM MVPs and has held the award since 2005.