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.
Publiez les résultats des tests sur VSTS/TFS.
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.
#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.
# YAML Syntax is not supported in TFS 2018.
# Use the classic designer to add and configure tasks.
# See the following Inputs section for details on the inputs that this task supports.
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 à dossier unique (
*
) 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 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
.
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 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 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 de 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.
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.
testRunner
- Format des résultats du test
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.
platform
- Plate-forme
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.
configuration
- 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.
Options de contrôle des tâches
Toutes les tâches ont des options de contrôle en plus de leurs entrées de tâche. 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âche CLI Dot NetCore , publient automatiquement les résultats des tests dans le pipeline. Les tâches telles que Ant, Maven, Gulp, Grunt et Xcode fournissent 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 sont affichés sous l’onglet Tests du résumé du pipeline. Les résultats vous aident à mesurer la qualité du pipeline, à examiner la traçabilité, à résoudre les défaillances et à gérer 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 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. Lors de l’utilisation de 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 | Visual Studio Test (TRX) |
---|---|---|
Exécuter le test | 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 de fin : date de début | |
Pièces jointes | Reportez-vous à la section prise en charge des pièces jointes ci-dessous. | |
Résultat du test | 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 la 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 | |
Priority | /TestRun/TestDefinitions/UnitTest.Attributes["priority"]. Valeur |
Notes
La durée n’est utilisée que lorsque Date de démarrage et Date terminée 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.
Prise en charge des pièces jointes
La tâche Publier les résultats des tests prend en charge les pièces jointes pour les 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 | Path |
---|---|---|
Exécuter le test | 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ésultat du 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/UriAttachments/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érer et tester avec un fichier Dockerfile à plusieurs étapes : les builds et les tests s’exécutent à l’intérieur du conteneur à l’aide d’un fichier Docker à plusieurs étapes, en tant que tels les résultats des tests 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 pour être publiés 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
Créez un
Dockerfile.build
fichier à la racine du répertoire de votre 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 que l’image finale soit aussi petite que possible, contenant uniquement les artefacts d’exécution et de déploiement, remplacez le contenu de l’existant
Dockerfile
par ce qui suit :# 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
.vsts-ci.docker.yml
fichier par ce qui suit :# 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 (push) l’image vers ce registre, remplacez le contenu du
.vsts-ci.yml
fichier par ce qui suit :# 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 principale de 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 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 :
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
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 commande | Quelconque |
Variables paramétrables | Quelconque |
Version de l’agent | 2.0.0 ou version ultérieure |
Catégorie de la tâche | Test |