Accélérer les tests à l’aide de l’analyse d’impact des tests (TIA)

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

L’intégration continue (CI) est une pratique clé dans le secteur. Les intégrations sont fréquentes, et vérifiées avec une build automatisée qui exécute des tests de régression pour détecter les erreurs d’intégration dès que possible. Toutefois, à mesure que le codebase croît et mûrit, sa suite de tests de régression a tendance à croître également, jusqu’au point où l’exécution d’un test de régression complet peut nécessiter des heures. Cela ralentit la fréquence des intégrations et, en fin de compte, va à l’encontre de l’objectif de l’intégration continue. Afin d’avoir un pipeline CI qui se termine rapidement, certaines équipes reportent l’exécution de leurs tests plus longs à une phase distincte dans le pipeline. Toutefois, cela ne sert qu’à nuire davantage à l’intégration continue.

Au lieu de cela, activez l’analyse d’impact des tests (TIA, Test Impact Analysis) lors de l’utilisation de la tâche Visual Studio Test dans un pipeline de build. La TIA effectue une validation incrémentielle par sélection automatique de test. Elle sélectionne automatiquement uniquement le sous-ensemble de tests requis pour valider le code en cours de commit. Pour un commit de code donné entrant dans le pipeline CI/CD, la TIA sélectionne et exécute uniquement les tests appropriés requis pour valider ce commit. Par conséquent, cette série de tests se terminera plus rapidement. En cas d’échec, vous en serez informé plus tôt, et comme tout est délimité par la pertinence, l’analyse sera également plus rapide.

L’analyse d’impact des tests offre ce qui suit :

• Mécanisme de sélection de test robuste. Elle inclut les tests impactés existants, les tests ayant précédemment échoué et les tests nouvellement ajoutés.
• Solution de secours. S’il y a des commits et des scénarios que la TIA ne peut pas comprendre, tous les tests seront exécutés. L’étendue de la TIA est actuellement limitée au code managé et à la topologie d’ordinateur unique. Ainsi, par exemple, si le commit de code contient des modifications apportées à des fichiers HTML ou CSS, elle ne pourra pas les comprendre et exécutera par conséquent tous les tests.
• Remplacements configurables. Vous pouvez exécuter tous les tests à une périodicité configurée.

Toutefois, tenez compte des inconvénients suivants lors de l’utilisation de la TIA avec Visual Studio 2015 :

• Exécution de tests en parallèle. Dans ce cas, les tests s’exécutent en série.
• Exécution de tests avec la couverture du code activée. Dans ce cas, les données de couverture du code ne sont pas collectées.

Scénarios pris en charge par l’analyse d’impact des tests

Actuellement, la TIA est pris en charge pour ce qui suit :

• TFS 2017 Update 1 et versions ultérieures et Azure Pipelines
• La version 2.* de la tâche Visual Studio Test dans le pipeline de build
• Build vNext, avec plusieurs tâches VSTest
• VS2015 Update 3 et versions ultérieures sur l’agent de build
• Agents de build locaux et hébergés
• Flux de travail CI et dans la demande de tirage (pull request)
• Git, GitHub, autres dépôts Git et TFVC (y compris les dépôts TFVC partiellement mappés avec une solution de contournement)
• Interactions IIS (via REST, API SOAP), à l’aide de protocoles HTTP/HTTPS
• Tests automatisés
• Topologie d’ordinateur unique. Les tests et l’application (SUT) doivent être en cours d’exécution sur le même ordinateur
• Code managé (toute application .NET Framework, tout service .NET)

À l’heure actuelle, la TIA n’est pas prise en charge pour ce qui suit :

• Topologie multi-ordinateurs (où le test exerce une application déployée sur un autre ordinateur)
• Tests pilotés par les données
• Exécution de tests parallèles propres à l’adaptateur de test
• .NET Core
• UWP

Plus d’informations sur l’étendue de la TIA et les applications

Activer l'analyse d'impact des tests

La TIA est pris en charge via la version 2.* de la tâche Visual Studio Test. Si votre application est une application à un seul niveau, il vous suffit de cocher Exécuter uniquement les tests impactés dans l’interface utilisateur de la tâche. Le collecteur de données Impact de test est automatiquement configuré. Aucune étape supplémentaire n’est nécessaire.

Si votre application interagit avec un service dans le contexte d’IIS, vous devez également configurer le collecteur de données Impact de test pour qu’il s’exécute dans le contexte d’IIS à l’aide d’un fichier .runsettings. Voici un exemple qui crée cette configuration :

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <!-- This is the TestImpact data collector.-->
      <DataCollector uri="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>

Afficher les résultats de l’analyse d’impact des tests

La TIA est intégrée aux rapports de tests existants au niveau du récapitulatif et des détails, y compris les e-mails de notification.

Plus d’informations sur l’intégration de la TIA et d’Azure Pipelines

Gérer le comportement de l’analyse d’impact des tests

Vous pouvez influencer la façon dont les tests sont inclus ou ignorés pendant une série de tests :

• Via l’interface utilisateur de la tâche VSTest. La TIA peut être conditionnée pour exécuter tous les tests à une périodicité configurée. La définition de cette option est recommandée, et constitue le moyen de réglementer la sélection des tests.
• En définissant une variable de build. Même après que la TIA a été activée dans la tâche VSTest, elle peut être désactivée pour une build spécifique en affectant la valeur true à la variable DisableTestImpactAnalysis. Cela forcera la TIA à exécuter tous les tests pour cette build. Dans les builds suivantes, la TIA reviendra à la sélection de test optimisée.

Lorsque la TIA ouvre un commit et voit un type de fichier inconnu, elle exécute tous les tests. Bien que cela soit bon du point de vue de la sécurité, le réglage de ce comportement peut être utile dans certains cas. Par exemple :

• Affectez des chemins spécifiques à la variable TI_IncludePathFilters pour inclure uniquement ces chemins dans un dépôt auquel vous souhaitez que la TIA s’applique. Cela est utile lorsque les équipes utilisent un dépôt partagé. La définition de cette variable désactive la TIA pour tous les autres chemins non inclus dans le paramètre.
• Définissez la variable TIA_IncludePathFilters pour spécifier les types de fichiers qui n’influencent pas le résultat des tests et pour lesquels les modifications doivent être ignorées. Par exemple, pour ignorer les modifications apportées aux fichiers .csproj, définissez la variable sur la valeur !**\*.csproj.

Utilisez le modèle minimatch lors de la définition de variables; et séparez plusieurs éléments par un point-virgule.

Pour évaluer si la TIA sélectionne les tests appropriés :

• Validez manuellement la sélection. Un développeur qui connaît l’architecture du système testé et des tests peut valider manuellement la sélection des tests à l’aide des fonctionnalités de création de rapports de la TIA.
• Exécutez les tests sélectionnés par la TIA, puis tous les tests dans l’ordre. Dans un pipeline de build, utilisez deux tâches de test : l’une qui exécute uniquement les tests impactés (T1) et l’autre qui exécute tous les tests (T2). Si T1 réussit, vérifiez que T2 réussit également. En cas d’échec d’un test dans T1, vérifiez que T2 signale le même ensemble d’échecs.

Plus d’informations sur la configuration avancée de la TIA

Fournir des mappages de dépendances personnalisés

La TIA utilise des mappages de dépendances de la forme suivante.

TestMethod1
  dependency1
  dependency2
TestMethod2
  dependency1
  dependency3

La TIA peut générer un tel mappage de dépendances pour l’exécution de code managé. Lorsque ces dépendances résident dans des fichiers .cs et .vb, la TIA peut automatiquement surveiller les commits dans ces fichiers, puis exécuter des tests qui avaient ces fichiers sources dans leur liste de dépendances.

Vous pouvez étendre l’étendue de la TIA en fournissant explicitement le mappage des dépendances sous forme de fichier XML. Par exemple, vous pouvez prendre en charge le code dans d’autres langages, tels que JavaScript ou C++, ou prendre en charge le scénario dans lequel des tests et du code de produit s’exécutent sur différents ordinateurs. Le mappage peut même être approximatif, et l’ensemble de tests que vous souhaitez exécuter peut être spécifié en termes de filtre de cas de test, comme vous le feriez généralement dans les paramètres de tâche VSTest.

Le fichier XML doit être archivé dans votre dépôt, généralement au niveau racine. Ensuite, définissez la variable de build TIA.UserMapFile pour qu’elle pointe vers celui-ci. Par exemple, si le fichier se nomme TIAmap.xml, définissez la variable sur $(System.DefaultWorkingDirectory)/TIAmap.xml.

Pour obtenir un exemple de format de fichier XML, consultez Mappage de dépendances personnalisé TIA.

Voir aussi

• Vue d’ensemble de la TIA et intégration de VSTS
• Étendue et applications de la TIA
• Configuration avancée de la TIA
• Mappage de dépendances personnalisé TIA

Aide et support

• Consultez notre page de résolution des problèmes
• Obtenez des conseils sur Stack Overflow et de l’aide sur Developer Community