Speed up testing by using Test Impact Analysis (TIA)
Raksts
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Continuous Integration (CI) is a key practice in the industry. Integrations are frequent, and verified with an automated build that runs regression tests to detect integration errors as soon as possible. But, as the code base grows and matures, its regression test suite tends to grow as well - to the extent that running a full regression test might require hours. This testing slows down the frequency of integrations, and ultimately defeats the purpose of continuous integration.
To have a CI pipeline that completes quickly, some teams defer the execution of their longer running tests to a separate stage in the pipeline. But, this action only serves to further defeat continuous integration.
Instead, enable Test Impact Analysis (TIA) when using the Visual Studio Test
task in a build pipeline. TIA performs incremental validation by automatic test selection.
It automatically selects only the subset of tests required to validate the code being committed.
For a given code commit entering the CI/CD pipeline, TIA selects and runs only the relevant tests required to validate that commit.
Therefore, that test run completes more quickly, if there is a failure you get alerted sooner, and because it's all scoped by relevance, analysis is faster, too.
Test Impact Analysis has:
A robust test selection mechanism. It includes existing impacted tests, previously failing tests, and newly added tests.
Safe fallback. For commits and scenarios that TIA can't understand, it falls back to running all tests. TIA is currently scoped to only managed code, and single machine topology. So, for example, if the code commit contains changes to HTML or CSS files, it can't reason about them and falls back to running all tests.
Configurable overrides. You can run all tests at a configured periodicity.
However, be aware of the following caveats when using TIA with Visual Studio 2015:
Running tests in parallel. In this case, tests run serially.
Running tests with code coverage enabled. In this case, code coverage data doesn't get collected.
Test Impact Analysis supported scenarios
Test Impact Analysis (TIA) is supported for the following scenarios:
TIA is supported through Version 2.* of the Visual Studio Test task.
If your app is a single tier application, all you need to do is to check Run only impacted tests in the task UI.
The Test Impact data collector is automatically configured. No further steps are required.
If your application interacts with a service in the context of IIS, you must also configure the Test Impact data collector to run in the context of IIS by using a .runsettings file.
The following sample creates this configuration:
XML
<?xml version="1.0" encoding="utf-8"?><RunSettings><DataCollectionRunSettings><DataCollectors><!-- This is the TestImpact data collector.--><DataCollectoruri="datacollector://microsoft/TestImpact/1.0"assemblyQualifiedName="Microsoft.VisualStudio.TraceCollector.TestImpactDataCollector, Microsoft.VisualStudio.TraceCollector, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"friendlyName="Test Impact"><Configuration><!-- enable IIS data collection--><InstrumentIIS>True</InstrumentIIS><!-- file level data collection --><ImpactLevel>file</ImpactLevel><!-- any job agent related executable or any other service that the test is using needs to be profiled. --><ServicesToInstrument><Name>TeamFoundationSshService</Name></ServicesToInstrument></Configuration></DataCollector></DataCollectors></DataCollectionRunSettings></RunSettings>
View Test Impact Analysis outcome
TIA is integrated into existing test reporting at both the summary and details levels, including notification emails.
You can influence the way that tests are either included or ignored during a test run:
Through the VSTest task UI. TIA can be conditioned to run all tests at a configured periodicity. Setting this option is recommended, and is the means to regulate test selection.
By setting a build variable. Even after TIA is enabled in the VSTest task, you can disable it for a specific build by setting the variable DisableTestImpactAnalysis to true. This override forces TIA to run all tests for that build. In subsequent builds, TIA goes back to optimized test selection.
When TIA opens a commit and sees an unknown file type, it falls back to running all tests. While this action is good from a safety perspective, tuning this behavior might be useful in some cases. For example:
Set the TI_IncludePathFilters variable to specific paths to include only these paths in a repository for which you want TIA to apply. This action is useful when teams use a shared repository. Setting this variable disables TIA for all other paths not included in the setting.
Set the TIA_IncludePathFilters variable to specify file types that don't influence the outcome of tests and for which changes should be ignored. For example, to ignore changes to.csproj files set the variable to the value: !\*\*\\\*.csproj.
Use the minimatch pattern when setting variables, and separate multiple items with a semicolon.
To evaluate whether TIA is selecting the appropriate tests:
Manually validate the selection. A developer who knows how the SUT and tests are architected could manually validate the test selection using the TIA reporting capabilities.
Run TIA selected tests and then all tests in sequence. In a build pipeline, use two test tasks - one that runs only impacted Tests (T1) and one that runs all tests (T2). If T1 passes, check that T2 passes as well. If there was a failing test in T1, check that T2 reports the same set of failures.
TIA can generate a dependency map for managed code execution.
Where such dependencies reside in .cs and .vb files, TIA can automatically watch for commits into such files and then run tests that had these source files in their list of dependencies.
You can extend the scope of TIA by explicitly providing the dependencies map as an XML file.
For example, you might want to support code in other languages such as JavaScript or C++,
or support the scenario where tests and product code are running on different machines.
The mapping can even be approximate, and the set of tests you want to run can be specified in terms of a test case filter such as you would typically provide in the VSTest task parameters.
The XML file should be checked into your repository, typically at the root level. Then set the build variable TIA.UserMapFile to point to it.
For example, if the file is named TIAmap.xml,
set the variable to $(System.DefaultWorkingDirectory)/TIAmap.xml.
Pievienojieties meetup sērijai, lai kopā ar citiem izstrādātājiem un ekspertiem izveidotu mērogojamus AI risinājumus, kuru pamatā ir reālas lietošanas gadījumi.