Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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-*.xmlrecherche tous les fichiers XML dont les noms commencent parTEST-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.trxpar 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
- Conditions préalables
- tâche par défaut
- mappage des formats de résultats
- Pièces jointes prennent en charge les
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.
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 :
- .NET Framework 4.6.2 ou une version ultérieure
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
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.dllCe 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.Pour rendre l’image finale aussi petite que possible, contenant uniquement les artefacts d’exécution et de déploiement, remplacez le contenu du
Dockerfileexistant 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 avez un compte Docker Hub et que vous souhaitez envoyer (push) l’image à votre registre Docker, remplacez le contenu du fichier
.vsts-ci.docker.ymlpar 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.ymlpar 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)Envoyez la modification à la branche principale dans votre référentiel.
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.
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
-
du poolAgent :
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 |