Partager via


PublishTestResults@2 - Publier la tâche Résultats des tests v2

Publiez les résultats des tests sur Azure Pipelines.

Syntaxe

# Publish Test Results v2
# Publish test results to Azure Pipelines.
- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit' # 'JUnit' | 'NUnit' | 'VSTest' | 'XUnit' | 'CTest'. Alias: testRunner. Required. Test result format. Default: JUnit.
    testResultsFiles: '**/TEST-*.xml' # string. Required. Test results files. Default: **/TEST-*.xml.
    #searchFolder: '$(System.DefaultWorkingDirectory)' # string. Search folder. Default: $(System.DefaultWorkingDirectory).
    #mergeTestResults: false # boolean. Merge test results. Default: false.
    #failTaskOnFailedTests: false # boolean. Fail if there are test failures. Default: false.
    #failTaskOnFailureToPublishResults: false # boolean. Fail if there is failure in publishing test results. Default: false.
    #failTaskOnMissingResultsFile: false # boolean. Fail if no result files are found. Default: false.
    #testRunTitle: # string. Test run title. 
  # Advanced
    #buildPlatform: # string. Alias: platform. Build Platform. 
    #buildConfiguration: # string. Alias: configuration. Build Configuration. 
    #publishRunAttachments: true # boolean. Upload test results files. Default: true.
# Publish Test Results v2
# Publish test results to Azure Pipelines.
- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit' # 'JUnit' | 'NUnit' | 'VSTest' | 'XUnit' | 'CTest'. Alias: testRunner. Required. Test result format. Default: JUnit.
    testResultsFiles: '**/TEST-*.xml' # string. Required. Test results files. Default: **/TEST-*.xml.
    #searchFolder: '$(System.DefaultWorkingDirectory)' # string. Search folder. Default: $(System.DefaultWorkingDirectory).
    #mergeTestResults: false # boolean. Merge test results. Default: false.
    #failTaskOnFailedTests: false # boolean. Fail if there are test failures. Default: false.
    #testRunTitle: # string. Test run title. 
  # Advanced
    #buildPlatform: # string. Alias: platform. Build Platform. 
    #buildConfiguration: # string. Alias: configuration. Build Configuration. 
    #publishRunAttachments: true # boolean. Upload test results files. Default: true.

Entrées

testResultsFormat - format de résultat de test
Alias d’entrée : testRunner. string. Obligatoire. Valeurs autorisées : JUnit, NUnit, VSTest, XUnit, CTest. Valeur par défaut : JUnit.

Spécifie le format des fichiers de résultats que vous souhaitez publier. Les formats suivants sont pris en charge : CTest, JUnit, NUnit 2, NUnit 3, Visual Studio Test (TRX) et xUnit 2.

Conseil / Astuce

VSTest format fait référence au format TRX. Ainsi, il fonctionne également si vous produisez TRX avec Microsoft.Testing.Platform (MTP) et n’est pas spécifique à VSTest. La valeur est VSTest pour des raisons historiques, avant l’introduction de MTP.


testResultsFiles - fichiers de résultats de test
string. Obligatoire. Valeur par défaut : **/TEST-*.xml.

Spécifie un ou plusieurs fichiers de résultats de test.

  • Vous pouvez utiliser un caractère générique à dossier unique (*) et des caractères génériques récursifs (**). Par exemple, **/TEST-*.xml recherche tous les fichiers XML dont les noms commencent par TEST- dans tous les sous-répertoires. Si vous utilisez VSTest comme format de résultat de test, le type de fichier doit être modifié en .trx par exemple **/TEST-*.trx
  • Plusieurs chemins d’accès peuvent être spécifiés, séparés par une nouvelle ligne.
  • Accepte également modèles de mini-correspondance.

Par exemple, !TEST[1-3].xml exclut les fichiers nommés TEST1.xml, TEST2.xmlou TEST3.xml.


searchFolder - dossier De recherche
string. Valeur par défaut : $(System.DefaultWorkingDirectory).

Optionnel. Spécifie le dossier à rechercher dans les fichiers de résultats de test.


mergeTestResults - Fusionner les résultats des tests
boolean. Valeur par défaut : false.

Lorsque cette valeur booléenne est true, la tâche signale les résultats des tests de tous les fichiers par rapport à une seule exécution de test . Si la valeur est false, la tâche crée une exécution de test distincte pour chaque fichier de résultats de test. Pour optimiser les performances, les résultats seront toujours fusionnés dans une seule exécution s’il y a plus de 100 fichiers de résultats, même si cette option est définie sur false.

Remarque

Utilisez le paramètre de résultats de test de fusion pour combiner des fichiers à partir du même framework de test pour vous assurer que le mappage et la durée des résultats sont calculés correctement.


failTaskOnFailedTests - Échec s’il existe des échecs de test
boolean. Valeur par défaut : false.

Optionnel. Lorsque cette valeur booléenne est true, la tâche échoue si l’un des tests du fichier de résultats est marqué comme ayant échoué. La valeur par défaut est false, qui publiera simplement les résultats à partir du fichier de résultats.


failTaskOnFailureToPublishResults - Échec en cas d’échec de publication des résultats de test
boolean. Valeur par défaut : false.

Lorsque true, échoue la tâche en cas d’échec de la publication des résultats des tests.


failTaskOnMissingResultsFile - Échouer si aucun fichier de résultat n’est trouvé
boolean. Valeur par défaut : false.

Échec de la tâche si aucun fichier de résultat n’est trouvé.


testRunTitle - titre d’exécution de test
string.

Optionnel. Spécifie un nom pour l’exécution de test sur laquelle les résultats seront signalés. Les noms de variables déclarés dans le pipeline de build ou de mise en production peuvent être utilisés.


buildPlatform - Créer une plateforme
Alias d’entrée : platform. string.

Optionnel. Spécifie la plateforme de génération sur laquelle l’exécution de test doit être signalée. Par exemple : x64 ou x86. Si vous avez défini une variable pour la plateforme dans votre tâche de génération, utilisez-la ici.


buildConfiguration - Build Configuration
Alias d’entrée : configuration. string.

Optionnel. Spécifie la configuration de build sur laquelle l’exécution de test doit être signalée. Par exemple : Debug ou Release. Si vous avez défini une variable pour la configuration dans votre tâche de génération, utilisez-la ici.


publishRunAttachments - Charger des fichiers de résultats de test
boolean. Valeur par défaut : true.

Optionnel. Lorsque cette valeur booléenne est true, la tâche charge tous les fichiers de résultats de test sous forme de pièces jointes à l’exécution de test.


Options de contrôle de la tâche

Toutes les tâches ont des options de contrôle en plus de leurs entrées de tâches. Pour plus d’informations, consultez Options de contrôle et propriétés de tâche courantes.

Variables de sortie

Aucun.

Remarques

Cette tâche publie les résultats des tests dans Azure Pipelines ou TFS lorsque des tests sont exécutés pour fournir une expérience complète de création de rapports et d’analytique de test. Vous pouvez utiliser l’exécuteur de test de votre choix qui prend en charge le format de résultats dont vous avez besoin. Les formats de résultats pris en charge incluent CTest, JUnit (y compris PHPUnit), NUnit 2, NUnit 3, Visual Studio Test (TRX) et xUnit 2.

D’autres tâches intégrées, telles que tâche de test Visual Studio et tâche CLI Dot NetCore publier automatiquement les résultats des tests sur le pipeline. Les tâches telles que Ant, Maven, Gulp, Gruntet Xcode fournissent des résultats de publication sous forme d’option dans la tâche ou créent des bibliothèques telles que Cobertura et JaCoCo. Si vous utilisez l’une de ces tâches, vous n’avez pas besoin d’un publier des résultats de test tâche dans le pipeline.

Les résultats des tests publiés sont affichés sous l’onglet Tests dans le résumé du pipeline. Les résultats vous aident à mesurer la qualité du pipeline, à passer en revue la traçabilité, à résoudre les défaillances et à gérer la propriété des défaillances du lecteur.

L’exemple suivant montre que la tâche est configurée pour publier les résultats des tests.

Ouvrir la page d’historique des tests

Vous pouvez également utiliser cette tâche dans un pipeline de build pour publier les résultats de couverture du code générés lors de l’exécution de tests sur Azure Pipelines ou TFS afin d’obtenir des rapports de couverture.

Conditions préalables

Si vous utilisez un agent auto-hébergé Windows, votre ordinateur doit disposer de cette configuration requise :

Valeurs par défaut de la tâche

L’option par défaut utilise le format JUnit pour publier les résultats des tests. Lors de l’utilisation de VSTest comme testRunner, l’option testResultsFiles doit être modifiée en **/TEST-*.trx.

testResultsFormat est un alias pour le nom d’entrée testRunner. Les fichiers de résultats peuvent être générés par plusieurs exécuteurs, pas seulement par un exécuteur spécifique. Par exemple, le format de résultats jUnit est pris en charge par de nombreux exécuteurs et pas seulement par jUnit.

Pour publier les résultats des tests pour Python à l’aide de YAML, consultez Python dans la section Ecosystems de ces rubriques, qui inclut également des exemples pour d’autres langages.

Mappage des formats de résultats

Ce tableau répertorie les champs signalés dans l’onglet Tests dans un résumé de build ou de mise en production, ainsi que le mappage correspondant avec les attributs dans les formats de résultats de test pris en charge.

Étendue Champ Test Visual Studio (TRX)
d’exécution de test Titre titre d’exécution de test spécifié dans la tâche
Date de début /TestRun/Times.Attributes[ »démarrer« ]. Valeur
Date terminée /TestRun/Times.Attributes[ »terminer« ]. Valeur
Durée Date terminée - Date de début
Pièces jointes Reportez-vous à section prise en charge des pièces jointes ci-dessous
résultat de test Titre /TestRun/Results/UnitTestResult.Attributes[ »testName« ]. Valeur ou /TestRun/Results/WebTestResult.Attributes[ »testName« ]. Valeur ou /TestRun/Results/TestResultAggregation.Attributes[ »testName« ]. Valeur
Date de début /TestRun/Results/UnitTestResult.Attributes[ »startTime« ]. Valeur ou /TestRun/Results/WebTestResult.Attributes[ »startTime« ]. Valeur ou /TestRun/Results/TestResultAggregation.Attributes[ »startTime« ]. Valeur
Date terminée /TestRun/Results/UnitTestResult.Attributes[ »startTime« ]. Valeur + /TestRun/Results/UnitTestResult.Attributes[ »durée« ]. Valeur ou /TestRun/Results/WebTestResult.Attributes[ »startTime« ]. Valeur + /TestRun/Results/WebTestResult.Attributes[ »durée« ]. Valeur ou /TestRun/Results/TestResultAggregation.Attributes[ »startTime« ]. Valeur + /TestRun/Results/TestResultAggregation.Attributes[ »durée« ]. Valeur
Durée /TestRun/Results/UnitTestResult.Attributes[ »durée« ]. Valeur ou /TestRun/Results/WebTestResult.Attributes[ »durée« ]. Valeur ou /TestRun/Results/TestResultAggregation.Attributes[ »durée« ]. Valeur
Propriétaire /TestRun/TestDefinitions/UnitTest/Owners/Owner.Attributes[ »nom« ]. Valeur
Résultat /TestRun/Results/UnitTestResult.Attributes[ »résultat« ]. Valeur ou /TestRun/Results/WebTestResult.Attributes[ »résultat« ]. Valeur ou /TestRun/Results/TestResultAggregation.Attributes[ »résultat« ]. Valeur
Message d'erreur /TestRun/Results/UnitTestResult/Output/ErrorInfo/Message.InnerText ou /TestRun/Results/WebTestResultOutput/ErrorInfo/Message.InnerText ou /TestRun/Results/TestResultAggregation/Output/ErrorInfo/Message.InnerText
Trace de pile /TestRun/Results/UnitTestResult/Output/ErrorInfo/StackTrace.InnerText ou /TestRun/Results/WebTestResultOutput/ErrorInfo/StackTrace.InnerText Ou /TestRun/Results/TestResultAggregation/Output/ErrorInfo/StackTrace.InnerText
Pièces jointes Reportez-vous à section prise en charge des pièces jointes ci-dessous
Journal de la console /TestRun/Results/UnitTestResult/Output/StdOut.InnerText ou /TestRun/Results/WebTestResultOutput/Output/StdOut.InnerText Ou /TestRun/Results/TestResultAggregation/Output/StdOut.InnerText
Journal des erreurs de la console /TestRun/Results/UnitTestResult/Output/StdErr.InnerText or /TestRun/Results/WebTestResultOutput/Output/StdErr.InnerText Or /TestRun/Results/TestResultAggregation/Output/StdErr.InnerText
Nom de l’agent /TestRun/Results/UnitTestResult.Attributes[ »computerName« ]. Valeur ou /TestRun/Results/WebTestResult.Attributes[ »computerName« ]. Valeur ou /TestRun/Results/TestResultAggregation.Attributes[ »computerName« ]. Valeur
Fichier de test /TestRun/TestDefinitions/UnitTest.Attributes[ »stockage« ]. Valeur
Priorité /TestRun/TestDefinitions/UnitTest.Attributes[ »priorité« ]. Valeur

Remarque

Durée est utilisée uniquement lorsque Date de démarrage et Date terminée ne sont pas disponibles.

Le format de nom complet de testName est Namespace.Testclass.Methodname avec une limite de caractères de 512. Si le test est piloté par les données et a des paramètres, la limite de caractères inclut les paramètres.

Lors de la publication du résultat du test, vous pouvez obtenir cette erreur : Échec de la publication des résultats de test : Priorité non valide spécifiée

Cette erreur se produit si l’une des méthodes de test a la priorité définie au-dessus de 255, corrigez la priorité de la méthode de test dans le code et réexécutez les tests. Vous pouvez consulter le fichier trx généré pour voir tous les tests ayant la priorité supérieure à 255.

Prise en charge des pièces jointes

La tâche Publier les résultats des tests fournit la prise en charge des pièces jointes pour l’exécution de test et les résultats des tests pour les formats suivants. Pour les projets publics, nous prenons en charge 2 Go de pièces jointes totales.

Test Visual Studio (TRX)

Étendue Catégorie Chemin
d’exécution de test Collecteur de données /TestRun/ResultSummary/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes[ »href« ]. Valeur
Résultat du test /TestRun/ResultSummary/ResultFiles/ResultFile.Attributes[ »chemin d’accès« ]. Valeur
Couverture du code /TestRun/TestSettings/Execution/AgentRule/DataCollectors/DataCollector/Configuration/CodeCoverage/Regular/CodeCoverageItem.Attributes[ »binaryFile« ]. Value and /TestRun/TestSettings/Execution/AgentRule/DataCollectors/DataCollector/Configuration/CodeCoverage/Regular/CodeCoverageItem.Attributes[ »pdbFile« ]. Valeur
résultat de test Collecteurs de données /TestRun/Results/UnitTestResult/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes[ »href« ]. Value or /TestRun/Results/WebTestResult/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes[ »href« ]. Value or /TestRun/Results/TestResultAggregation/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes[ »href« ]. Valeur
Résultat du test /TestRun/Results/UnitTestResult/ResultFiles/ResultFile.Attributes[ »chemin d’accès« ]. Valeur ou /TestRun/Results/WebTestResult/ResultFiles/ResultFile.Attributes[ »chemin d’accès« ]. Valeur ou /TestRun/Results/TestResultAggregation/ResultFiles/ResultFile.Attributes[ »chemin d’accès« ]. Valeur

Remarque

L’option permettant de charger le fichier de résultats de test en tant que pièce jointe est une option par défaut dans la tâche, applicable à tous les formats.

Exemples

Docker

Pour les applications Docker, il existe de nombreuses façons de créer votre application et d’exécuter des tests :

  • Générer et tester dans un pipeline de build: les builds et les tests s’exécutent dans le pipeline et les résultats des tests sont publiés à l’aide de la tâche Publier les résultats de test.
  • Générer et tester avec unfichier Dockerfile à plusieurs étapes : les builds et les tests s’exécutent à l’intérieur du conteneur à l’aide d’un fichier Docker à plusieurs étapes, car ces résultats de test ne sont pas publiés dans le pipeline.
  • Générer, tester et publier des résultats avec un fichier Dockerfile: les builds et les tests s’exécutent à l’intérieur du conteneur, et les résultats sont publiés dans le pipeline. Consultez l’exemple ci-dessous.

Générer, tester et publier des résultats avec un fichier Docker

Dans cette approche, vous générez votre code et exécutez des tests à l’intérieur du conteneur à l’aide d’un fichier Docker. Les résultats des tests sont ensuite copiés sur l’hôte à publier dans le pipeline. Pour publier les résultats des tests sur Azure Pipelines, vous pouvez utiliser la tâche Publier les résultats des tests. L’image finale sera publiée sur Docker ou Azure Container Registry.

Obtenir le code
  1. Créez un fichier Dockerfile.build à la racine de votre répertoire de projet avec les éléments suivants :

    # Build and run tests inside the docker container
    FROM mcr.microsoft.com/dotnet/sdk:2.1
    WORKDIR /app
    # copy the contents of agent working directory on host to workdir in container
    COPY . ./
    # dotnet commands to build, test, and publish
    RUN dotnet restore
    RUN dotnet build -c Release
    RUN dotnet test dotnetcore-tests/dotnetcore-tests.csproj -c Release --logger "trx;LogFileName=testresults.trx"
    RUN dotnet publish -c Release -o out
    ENTRYPOINT dotnet dotnetcore-sample/out/dotnetcore-sample.dll
    

    Ce fichier contient les instructions permettant de générer du code et d’exécuter des tests. Les tests sont ensuite copiés dans un fichier testresults.trx à l’intérieur du conteneur.

  2. Pour rendre l’image finale aussi petite que possible, contenant uniquement les artefacts d’exécution et de déploiement, remplacez le contenu du Dockerfile existant par les éléments suivants :

    # This Dockerfile creates the final image to be published to Docker or
    # Azure Container Registry
    # Create a container with the compiled asp.net core app
    FROM mcr.microsoft.com/dotnet/aspnet:2.1
    # Create app directory
    WORKDIR /app
    # Copy only the deployment artifacts
    COPY /out .
    ENTRYPOINT ["dotnet", "dotnetcore-sample.dll"]
    
Définir le pipeline de build
  1. Si vous avez un compte Docker Hub et que vous souhaitez envoyer (push) l’image à votre registre Docker, remplacez le contenu du fichier .vsts-ci.docker.yml par les éléments suivants :

    # Build Docker image for this app, to be published to Docker Registry
    pool:
      vmImage: 'ubuntu-latest'
    variables:
      buildConfiguration: 'Release'
    steps:
    - script: |
        docker build -f Dockerfile.build -t $(dockerId)/dotnetcore-build:$BUILD_BUILDID .
        docker run --name dotnetcoreapp --rm -d $(dockerId)/dotnetcore-build:$BUILD_BUILDID
        docker cp dotnetcoreapp:app/dotnetcore-tests/TestResults $(System.DefaultWorkingDirectory)
        docker cp dotnetcoreapp:app/dotnetcore-sample/out $(System.DefaultWorkingDirectory)
        docker stop dotnetcoreapp
    
    - task: PublishTestResults@2
      inputs:
        testRunner: VSTest
        testResultsFiles: '**/*.trx'
        failTaskOnFailedTests: true
    
    - script: |
        docker build -f Dockerfile -t $(dockerId)/dotnetcore-sample:$BUILD_BUILDID .
        docker login -u $(dockerId) -p $pswd
        docker push $(dockerId)/dotnetcore-sample:$BUILD_BUILDID
      env:
        pswd: $(dockerPassword)
    

    Sinon, si vous configurez azure Container Registry et que vous souhaitez envoyer (push) l’image à ce registre, remplacez le contenu du fichier .vsts-ci.yml par les éléments suivants :

    # Build Docker image for this app to be published to Azure Container Registry
    pool:
      vmImage: 'ubuntu-latest'
    variables:
      buildConfiguration: 'Release'
    
    steps:
    - script: |
        docker build -f Dockerfile.build -t $(dockerId)/dotnetcore-build:$BUILD_BUILDID .
        docker run --name dotnetcoreapp --rm -d $(dockerId)/dotnetcore-build:$BUILD_BUILDID
        docker cp dotnetcoreapp:app/dotnetcore-tests/TestResults $(System.DefaultWorkingDirectory)
        docker cp dotnetcoreapp:app/dotnetcore-sample/out $(System.DefaultWorkingDirectory)
        docker stop dotnetcoreapp
    
    - task: PublishTestResults@2
      inputs:
        testRunner: VSTest
        testResultsFiles: '**/*.trx'
        failTaskOnFailedTests: true
    
    - script: |
        docker build -f Dockerfile -t $(dockerId).azurecr.io/dotnetcore-sample:$BUILD_BUILDID .
        docker login -u $(dockerId) -p $pswd $(dockerid).azurecr.io
        docker push $(dockerId).azurecr.io/dotnetcore-sample:$BUILD_BUILDID 
      env:
        pswd: $(dockerPassword)
    
  2. Envoyez la modification à la branche principale dans votre référentiel.

  3. Si vous utilisez Azure Container Registry, vérifiez que vous avez précréé le registre dans le portail Azure. Copiez le nom d’utilisateur administrateur et le mot de passe affichés dans la section clés d’accès des paramètres du Registre dans le portail Azure.

  4. Mettre à jour votre pipeline de build avec les éléments suivants

    • du poolAgent : Hosted Ubuntu 1604
      • dockerId: définissez la valeur sur votre ID Docker pour DockerHub ou le nom d’utilisateur administrateur d’Azure Container Registry.
      • dockerPassword: définissez la valeur sur votre mot de passe pour DockerHub ou le mot de passe administrateur Azure Container Registry.
    • chemin d’accès au fichier YAML: /.vsts-ci.docker.yml
  5. Mettez en file d’attente une nouvelle build et regardez-la créer et envoyer (push) une image Docker à votre registre et les résultats des tests vers Azure DevOps.

Spécifications

Besoin Descriptif
Types de pipelines YAML, Build Classique, Version Classique
Exécutions sur Agent, DeploymentGroup
demandes Aucun
fonctionnalités de Cette tâche ne répond à aucune demande de tâches ultérieures dans le travail.
restrictions de commande N'importe quel
variables settables N'importe quel
Version de l’agent 2.0.0 ou version ultérieure
Catégorie de tâche Essai