doc-locale/fr-fr/ci/testing/unit_test_reports.md
{{< details >}}
{{< /details >}}
Les rapports de tests unitaires affichent les résultats des tests directement dans les merge requests et les détails du pipeline, ce qui vous permet d'identifier les échecs sans parcourir les job logs.
Utilisez les rapports de tests unitaires lorsque vous souhaitez :
Les rapports de tests unitaires nécessitent le format JUnit XML et n'affectent pas le statut du job. Pour qu'un job échoue lorsque les tests échouent, le script de votre job doit se terminer avec un statut non nul.
GitLab Runner charge vos résultats de tests au format JUnit XML en tant qu'artefacts. Lorsque vous accédez à une merge request, vos résultats de tests sont comparés entre la branche source (head) et la branche cible (base) afin de montrer ce qui a changé.
Les rapports de tests unitaires doivent utiliser le format JUnit XML avec des exigences spécifiques pour garantir un parsing et un affichage corrects.
Vos fichiers de rapport de tests doivent :
.xml.Si vous avez des noms de tests en double, seul le premier test est utilisé et les autres portant le même nom sont ignorés.
Pour les limites des cas de test, consultez Nombre maximum de cas de test par rapport de tests unitaires.
GitLab parse un sous-ensemble d'éléments et d'attributs JUnit XML pour afficher les résultats des tests dans l'interface utilisateur.
| Élément XML | Attribut XML | Description |
|---|---|---|
testsuites | time | Temps d'exécution total pour toutes les suites de tests. Utilisé pour les calculs du temps d'exécution des tests. |
testsuite | name | Nom de la suite de tests. Parsé pour le regroupement interne. |
testsuite | time | Temps d'exécution pour une suite de tests individuelle. Utilisé pour les calculs du temps d'exécution des tests. |
testcase | classname | Nom de la classe ou de la catégorie de test. Affiché comme nom de suite dans l'interface utilisateur. |
testcase | name | Nom du test individuel. |
testcase | file | Chemin du fichier où le test est défini. |
testcase | time | Temps d'exécution du test en secondes. |
failure | Contenu de l'élément | Message d'échec et trace de pile. |
error | Contenu de l'élément | Message d'erreur et trace de pile. |
skipped | Contenu de l'élément | Raison du saut du test. |
system-out | Contenu de l'élément | Sortie système et balises de pièces jointes. Parsé uniquement depuis les éléments testcase. |
system-err | Contenu de l'élément | Sortie d'erreur système. Parsé uniquement depuis les éléments testcase. |
Les éléments et attributs suivants ne sont pas parsés :
testsuite (tests, failures, errors, timestamp)testcase (assertions, line, status)propertiessystem-out et system-err au niveau testsuite<testsuites>
<testsuite name="Authentication Tests" tests="1" failures="1">
<testcase classname="LoginTest" name="test_invalid_password" file="spec/auth_spec.rb" time="0.23">
<failure>Expected authentication to fail</failure>
[[ATTACHMENT|screenshots/failure.png]]
</testcase>
</testsuite>
</testsuites>
Ce XML s'affiche dans GitLab comme suit :
LoginTest (depuis testcase classname)test_invalid_password (depuis testcase name)spec/auth_spec.rb (depuis testcase file)0.23s (depuis testcase time)testcase system-out)testsuite name)Les résultats des tests sont comparés entre la branche source et la branche cible de la merge request afin de montrer ce qui a changé :
Si les branches ne peuvent pas être comparées, par exemple lorsqu'il n'y a pas encore de données pour la branche cible, seuls les tests en échec de votre branche sont affichés.
Pour les tests qui ont échoué sur la branche par défaut au cours des 14 derniers jours, un message de type Failed {n} time(s) in {default_branch} in the last 14 days s'affiche. Ce décompte inclut les tests en échec des pipelines terminés, mais pas les pipelines bloqués. La prise en charge des pipelines bloqués est proposée dans le ticket 431265.
Configurez les rapports de tests unitaires pour afficher les résultats des tests dans les merge requests et les pipelines.
Pour configurer les rapports de tests unitaires :
Configurez votre job de test pour générer des rapports de tests au format JUnit XML. Pour les détails de configuration, consultez la documentation de votre framework de test.
Dans votre fichier .gitlab-ci.yml, ajoutez artifacts:reports:junit à votre job de test.
Spécifiez le chemin vers vos fichiers de rapport de tests XML. La propriété junit accepte :
junit: report.xmljunit: test-results/**/*.xmljunit: [rspec-1.xml, rspec-2.xml, rspec-3.xml]junit: [rspec.xml, test-results/TEST-*.xml]Les répertoires ne sont pas pris en charge (par exemple, junit: test-results ou junit: test-results/**).
Facultatif. Pour rendre les fichiers de rapport navigables, incluez-les avec artifacts:paths.
Facultatif. Pour charger les rapports même lorsque les jobs échouent, utilisez artifacts:when:always.
Exemple de configuration pour Ruby avec RSpec :
ruby:
stage: test
script:
- bundle install
- bundle exec rspec --format progress --format RspecJunitFormatter --out rspec.xml
artifacts:
when: always
paths:
- rspec.xml
reports:
junit: rspec.xml
Vous pouvez consulter les résultats des tests :
Affichez des informations détaillées sur les échecs de tests dans les merge requests.
Le panneau Synthèse des tests affiche une vue d'ensemble de vos résultats de tests, notamment le nombre de tests en échec et en succès.
Pour afficher les détails des échecs de tests :
La boîte de dialogue affiche le nom du test, le chemin du fichier, le temps d'exécution, la pièce jointe de capture d'écran (si configurée) et la sortie d'erreur.
Pour afficher tous les résultats des tests :
Copiez les noms des tests pour les réexécuter localement à des fins de débogage.
Prérequis :
<file> pour les tests en échec.Pour copier tous les noms des tests en échec :
Les tests en échec sont copiés sous forme de chaîne de caractères séparée par des espaces.
Pour copier un seul nom de test en échec :
Le nom du test est copié dans votre presse-papiers.
Affichez toutes les suites et cas de tests dans les détails du pipeline, y compris les résultats des pipelines enfants.
Pour afficher les résultats des tests du pipeline :
Vous pouvez également récupérer les rapports de tests avec l'API Pipelines.
Les résultats des tests affichent différentes métriques de durée :
Durée du pipeline : Temps écoulé entre le démarrage et la fin du pipeline.
Temps d'exécution des tests : Temps total passé à exécuter tous les tests sur tous les jobs, additionné.
Temps d'attente en file : Temps passé par les jobs à attendre des runners disponibles.
Lorsque les jobs s'exécutent en parallèle, le temps d'exécution cumulé des tests peut dépasser la durée du pipeline.
La durée du pipeline indique le temps d'attente des résultats, tandis que le temps d'exécution des tests indique les ressources de calcul utilisées.
Par exemple, un pipeline qui se termine en 81 minutes peut afficher 9 heures 10 minutes de temps d'exécution des tests si de nombreux jobs de test s'exécutent en parallèle sur plusieurs runners.
Ajoutez des captures d'écran aux rapports de tests pour faciliter le débogage des échecs de tests.
Pour ajouter des captures d'écran aux rapports de tests :
Dans votre fichier JUnit XML, ajoutez des balises de pièces jointes avec les chemins des captures d'écran relatifs à $CI_PROJECT_DIR :
<testcase time="1.00" name="Test">
[[ATTACHMENT|/path/to/some/file]]
</testcase>
Dans votre fichier .gitlab-ci.yml, configurez votre job pour charger les captures d'écran en tant qu'artefacts :
artifacts:when: always pour charger les captures d'écran lorsque les tests échouent.Par exemple :
ruby:
stage: test
script:
- bundle install
- bundle exec rspec --format progress --format RspecJunitFormatter --out rspec.xml
- # Your test framework should save screenshots to a directory
artifacts:
when: always
paths:
- rspec.xml
- screenshots/
reports:
junit: rspec.xml
Exécutez votre pipeline.
Vous pouvez accéder au lien de la capture d'écran dans la boîte de dialogue des détails du test lorsque vous sélectionnez Afficher les détails pour un test en échec dans le panneau Synthèse des tests.
Il est possible que le panneau Synthèse des tests apparaisse vide dans les merge requests.
Ce problème survient lorsque :
Pour résoudre ce problème, définissez une valeur expire_in plus longue pour l'artefact de rapport, ou exécutez un nouveau pipeline pour générer un nouveau rapport.
Si les fichiers JUnit dépassent les limites de taille, assurez-vous que :
La prise en charge des limites personnalisées est proposée dans l'epic 16374.
Il est possible que vous voyiez moins de résultats de tests que prévu dans vos rapports.
Cela peut se produire lorsque vous avez des noms de tests en double dans votre fichier JUnit XML. Seul le premier test pour chaque nom est utilisé et les doublons sont ignorés.
Pour résoudre ce problème, assurez-vous que tous les noms et classes de tests sont uniques.
Il est possible que le panneau Synthèse des tests n'apparaisse pas du tout dans les merge requests.
Ce problème peut survenir lorsque la branche cible ne dispose d'aucune donnée de test pour la comparaison.
Pour résoudre ce problème, exécutez un pipeline sur votre branche cible pour générer des données de test de référence.
Il est possible que des indicateurs d'erreur de parsing s'affichent en regard des noms de jobs dans votre pipeline.
Cela peut se produire lorsque les fichiers JUnit XML contiennent des erreurs de formatage ou des éléments non valides.
Pour résoudre ce problème :
Pour les jobs groupés, seule la première erreur de parsing du groupe est affichée.