PublishTestResults@2 - Tâche Publier les résultats des tests v2
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 parTEST-
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.xml
ou 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
- Composants requis
- Valeurs par défaut des tâches
- Mappage des formats de résultats
- Prise en charge des pièces jointes
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.
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 :
- .NET Framework 4.6.2 ou une version ultérieure
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
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.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
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)
Envoyez la modification à la branche main dans votre dépôt.
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.
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
- Pool d’agents :
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 |