PublishTestResults@2 - Tâche Publier les résultats des tests v2

  • Article

Publiez les résultats des tests dans Azure Pipelines.

Publiez les résultats des tests sur Azure Pipelines/TFS.

Syntax

# 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.

# Publish Test Results v2
# Publish Test Results to Azure Pipelines/TFS.
- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit' # 'JUnit' | 'NUnit' | 'VSTest' | 'XUnit'. 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.
    #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 des résultats du 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.


testResultsFormat - Format des résultats du test
Alias d’entrée : testRunner. string. Obligatoire. Valeurs autorisées : JUnit, NUnit, VSTest, XUnit. 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.


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 pour un seul dossier (*) et des caractères génériques récursifs (**). Par exemple, **/TEST-*.xml recherche tous les fichiers XML dont le nom commence 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 remplacé .trx par, par exemple. **/TEST-*.trx
  • Plusieurs chemins d’accès peuvent être spécifiés, séparés par une nouvelle ligne.
  • Accepte également les modèles de mini-correspondance.

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


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

facultatif. Spécifie le dossier dans lequel rechercher les fichiers de résultats de test.


mergeTestResults - Résultats des tests de fusion
boolean. Valeur par défaut : false.

Lorsque la valeur de ce booléen est true, la tâche signale les résultats des tests de tous les fichiers sur une seule série de tests. Si la valeur est false, la tâche crée une série de tests distincte pour chaque fichier de résultats de test.

Notes

Utilisez le paramètre de résultats de test de fusion pour combiner des fichiers de la même infrastructure de test afin de garantir que le mappage et la durée des résultats sont calculés correctement.


failTaskOnFailedTests - Échec en cas d’échecs de test
boolean. Valeur par défaut : false.

facultatif. Lorsque la valeur de ce booléen 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 publie simplement les résultats du fichier de résultats.


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

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


failTaskOnMissingResultsFile - Échec 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 de la série de tests
string.

facultatif. Spécifie un nom pour la série de tests pour 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 - Plateforme de génération
Alias d’entrée : platform. string.

facultatif. Spécifie la plateforme de build sur laquelle la série de tests 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.

facultatif. Spécifie la configuration de build par rapport à laquelle la série de tests 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.

facultatif. Lorsque la valeur de ce booléen est true, la tâche charge tous les fichiers de résultats de test sous forme de pièces jointes à la série de tests.


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.

Notes

Cette tâche publie les résultats des tests sur 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’analyse des tests. 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 la tâche de test Visual Studio et la tâcheCLI Dot NetCore , publient automatiquement les résultats des tests dans le pipeline. Les tâches telles que Ant, Maven, Gulp, Grunt et Xcodefournissent des résultats de publication en tant qu’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’une tâche de publication des résultats de test distincte dans le pipeline.

Les résultats des tests publiés s’affichent sous l’onglet Tests du 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 à piloter la propriété des défaillances.

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.

Prérequis

Si vous utilisez un agent auto-hébergé Windows, ce prérequis doit être installé sur votre ordinateur :

Valeurs par défaut des tâches

L’option par défaut utilise le format JUnit pour publier les résultats des tests. Lorsque vous utilisez VSTest comme testRunner, l’option testResultsFiles doit être remplacée par **/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 Écosystèmes 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 sous 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)
Série de tests Titre Titre de série de tests spécifié dans la tâche
Date de début /TestRun/Times.Attributes["start"]. Valeur
Date d'achèvement /TestRun/Times.Attributes["finish"]. Valeur
Duration Date d’achèvement - Date de début
Pièces jointes Reportez-vous à la section Prise en charge des pièces jointes ci-dessous.
Résultats des tests Titre /TestRun/Results/UnitTestResult.Attributes["testName"]. Value or /TestRun/Results/WebTestResult.Attributes["testName"]. Value or /TestRun/Results/TestResultAggregation.Attributes["testName"]. Valeur
Date de début /TestRun/Results/UnitTestResult.Attributes["startTime"]. Value or /TestRun/Results/WebTestResult.Attributes["startTime"]. Value or /TestRun/Results/TestResultAggregation.Attributes["startTime"]. Valeur
Date d'achèvement /TestRun/Results/UnitTestResult.Attributes["startTime"]. Value + /TestRun/Results/UnitTestResult.Attributes["duration"]. Value or /TestRun/Results/WebTestResult.Attributes["startTime"]. Value + /TestRun/Results/WebTestResult.Attributes["duration"]. Value or /TestRun/Results/TestResultAggregation.Attributes["startTime"]. Value + /TestRun/Results/TestResultAggregation.Attributes["duration"]. Valeur
Duration /TestRun/Results/UnitTestResult.Attributes["duration"]. Value or /TestRun/Results/WebTestResult.Attributes["duration"]. Value or /TestRun/Results/TestResultAggregation.Attributes["duration"]. Valeur
Propriétaire /TestRun/TestDefinitions/UnitTest/Owners/Owner.Attributes["name"]. Valeur
Résultat /TestRun/Results/UnitTestResult.Attributes["result"]. Value or /TestRun/Results/WebTestResult.Attributes["result"]. Value or /TestRun/Results/TestResultAggregation.Attributes["result"]. 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
Arborescence des appels de procédure /TestRun/Results/UnitTestResult/Output/ErrorInfo/StackTrace.InnerText or /TestRun/Results/WebTestResultOutput/ErrorInfo/StackTrace.InnerText or /TestRun/Results/TestResultAggregation/Output/ErrorInfo/StackTrace.InnerText
Pièces jointes Reportez-vous à la section Prise en charge des pièces jointes ci-dessous.
Journal de console /TestRun/Results/UnitTestResult/Output/StdOut.InnerText or /TestRun/Results/WebTestResultOutput/Output/StdOut.InnerText or /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"]. Value or /TestRun/Results/WebTestResult.Attributes["computerName"]. Value or /TestRun/Results/TestResultAggregation.Attributes["computerName"]. Valeur
Fichier de test /TestRun/TestDefinitions/UnitTest.Attributes["storage"]. Valeur
Priorité /TestRun/TestDefinitions/UnitTest.Attributes["priority"]. Valeur

Notes

La durée est utilisée uniquement lorsque Date de démarrage et Date d’achèvement ne sont pas disponibles.

Le format de nom complet pour 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 l’erreur suivante : Échec de la publication des résultats du test : Priorité non valide spécifiée

Cette erreur se produit si l’une des méthodes de test a une 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 passer en revue le fichier trx généré pour voir tous les tests dont la priorité est supérieure à 255.

Prise en charge des pièces jointes

La tâche Publier les résultats des tests prend en charge les pièces jointes pour la série de tests 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 Type Chemin d’accès
Série de tests Collecteur de données /TestRun/ResultSummary/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"]. Valeur
Résultat de test /TestRun/ResultSummary/ResultFiles/ResultFile.Attributes["path"]. 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ésultats des tests Collecteurs de données /TestRun/Results/UnitTestResult/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"]. Value ou /TestRun/Results/WebTestResult/CollectorDataEntries/Collector/UriAttachments/UriAttachments/A.Attributes["href"]. Value ou /TestRun/Results/TestResultAggregation/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"]. Valeur
Résultat de test /TestRun/Results/UnitTestResult/ResultFiles/ResultFile.Attributes["path"]. Value or /TestRun/Results/WebTestResult/ResultFiles/ResultFile.Attributes["path"]. Value or /TestRun/Results/TestResultAggregation/ResultFiles/ResultFile.Attributes["path"]. Valeur

Notes

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

Exemples

Docker

Pour les applications basées sur 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 des tests .
  • Générez et testez avec un 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 dockerfile : les builds et les tests s’exécutent à l’intérieur du conteneur, et les résultats sont publiés dans le pipeline. Reportez-vous à 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 dans 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 Dockerfile.build fichier à 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 pour générer du code et 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 de l’existant Dockerfile 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 disposez d’un compte Docker Hub et que vous souhaitez envoyer l’image à votre registre Docker, remplacez le contenu du fichier par les .vsts-ci.docker.yml é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)

    Si vous configurez un Azure Container Registry et que vous souhaitez envoyer l’image à ce registre, remplacez le contenu du fichier par les .vsts-ci.yml é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 main dans votre dépôt.

  3. Si vous utilisez Azure Container Registry, assurez-vous d’avoir précréé le Registre dans le Portail Azure. Copiez le nom d’utilisateur administrateur et le mot de passe indiqué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

    • Pool d’agents : Hosted Ubuntu 1604
      • dockerId : définissez la valeur sur votre ID Docker pour DockerHub ou le nom d’utilisateur administrateur pour 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 du fichier YAML : /.vsts-ci.docker.yml

  5. Mettre en file d’attente une nouvelle build et watch qu’elle crée et envoie une image Docker à votre registre et les résultats des tests vers Azure DevOps.

Configuration requise

Condition requise Description
Types de pipelines YAML, build classique, version classique
S’exécute sur Agent, DeploymentGroup
Demandes None
Capabilities Cette tâche ne répond à aucune demande pour les tâches suivantes dans le travail.
Restrictions de commandes Quelconque
Variables settables Quelconque
Version de l’agent 2.0.0 ou supérieur
Catégorie de la tâche Test