Section Overview

Test Visibility présente les métriques et les résultats importants de vos tests. Ces données sur les tests vous permettent de visualiser l’état de santé global de votre intégration continue. Cette page vous aide à étudier les problèmes de performance et les échecs de tests. Pour garantir la pertinence des données affichées, Datadog tient principalement compte du code auquel vous avez contribué, et accorde une importance moindre aux pipelines que vous gérez (même si les tests y sont exécutés).

Configuration

Sélectionnez une option pour configurer Test Visibility dans Datadog :

En plus des tests, Test Visibility offre une visibilité sur l’ensemble de la phase de test de votre projet.

Fonctionnalités prises en charge

* La fonctionnalité nécessite votre consentement. Elle doit être activée sur la page Test Service Settings.

Configurations par défaut

Les tests permettent d’évaluer le comportement du code avec un ensemble de conditions données. Certaines de ces conditions sont liées à l’environnement d’exécution des tests, comme le système d’exploitation ou le runtime utilisé. Le même code exécuté dans des conditions différentes peut avoir un comportement différent. C’est la raison pour laquelle les développeurs configurent généralement leurs tests de façon à les exécuter dans des conditions différentes et valider le comportement attendu pour chacun d’entre eux. Cet ensemble de conditions spécifiques est appelé configuration.

Dans Test Visibility, un test avec plusieurs configurations est traité comme plusieurs tests, avec un test correspondant à chaque configuration. Si l’une des configurations échoue mais les autres réussissent, seule cette combinaison test/configuration sera marquée comme ayant échoué

Imaginons par exemple que vous testiez un seul commit et que vous possédiez un test Python qui s’exécute dans trois versions différentes de Python. Si le test échoue pour l’une de ces versions, ce test spécifique est marqué comme ayant échoué, tandis que les autres versions sont marquées comme ayant réussi. Si vous relancez les tests avec le même commit et si le test des trois versions de Python réussit, le test effectué avec la version qui avait échoué est désormais marqué comme ayant réussi et ayant des irrégularités, tandis que les deux autres versions restent réussies, sans détection d’irrégularités.

Attributs de configuration de test

Lorsque vous exécutez vos tests avec Test Visibility, la bibliothèque détecte et signale les informations relatives à l’environnement dans lequel les tests sont exécutés sous forme de tags de tests. Par exemple, le nom du système d’exploitation, comme Windows ou Linux, ainsi que l’architecture de la plateforme, comme arm64 ou x86_64, sont ajoutés sous forme de tags à chaque test. Ces valeurs sont affichées dans le commit et sur les pages des aperçus des branches lorsqu’un test échoue ou est défaillant pour une configuration spécifique, mais pas pour les autres.

Les tags suivants sont collectés automatiquement pour identifier les configurations de test, et certains peuvent ne s’appliquer qu’à des plates-formes spécifiques :

Configurations de tests paramétrés

Lorsque vous exécutez des tests paramétrés, la bibliothèque détecte et signale les informations sur les paramètres utilisés. Les paramètres font partie d’une configuration de test, ce qui signifie que les mêmes scénarios de tests exécutés avec des paramètres différents sont considérés comme étant deux tests différents dans Test Visibility.

Si un paramètre de test n’est pas déterministe et possède une valeur différente à chaque exécution de test, alors chaque exécution de test est considérée comme étant un nouveau test dans Test Visibility. Ainsi, certaines fonctionnalités peuvent ne pas fonctionner correctement pour ces tests : historique des exécutions, détection des irrégularités, Intelligent Test Runner et d’autres encore.

Voici des exemples de paramètres de tests non déterministes :

• date actuelle
• une valeur aléatoire
• une valeur qui dépend de l’environnement dans lequel le test est exécuté (comme un chemin de fichier absolu ou le nom d’utilisateur actuel)
• une valeur qui ne possède pas de représentation de chaîne déterministe (par exemple, une instance d’une classe java dont la méthode toString() n’est pas remplacée)

Évitez d’utiliser des paramètres de test non déterministes. Si ce n’est pas possible, certains cadres d’application de tests permettent de spécifier une représentation de chaîne déterministe pour un paramètre non déterministe (comme le remplacement du nom d’affichage du paramètre).

Configurations personnalisées

Certaines configurations ne peuvent pas être directement identifiées et sont signalées automatiquement, car elles dépendent des variables d’environnement, des arguments d’exécution de tests ou d’autres approches utilisées par les développeurs. Dans ces situations, vous devez fournir les détails de la configuration dans la bibliothèque, afin que Test Visibility puisse les identifier correctement.

Définissez ces tags comme faisant partie de la variable d’environnement DD_TAGS à l’aide du préfixe test.configuration.

Par exemple, les tags de configuration de tests identifient une configuration de test où le délai de réponse du disque est long et où peu de mémoire est disponible :

DD_TAGS=test.configuration.disk:slow,test.configuration.memory:low

Tous les tags possédant le préfixe test.configuration sont utilisés comme étant des tags de configuration, en plus de ceux qui ont été collectés automatiquement.

Remarque : les tags test.configuration imbriqués, comme test.configuration.cpu.memory, ne sont pas pris en charge.

Pour appliquer un filtre avec ces tags de configuration, vous devez créer des facettes pour ces tags.

Améliorez vos processus de développement

Utiliser des données de tests CI

Lorsque la solution Test Visibility est activée, les données suivantes sont recueillies à partir de votre projet :

• Les noms et durées des tests
• Les variables d’environnement prédéfinies par les fournisseurs de CI
• L’historique de commits Git, y compris les informations sur les hashs, les messages et les auteurs, ainsi que sur les modifications de fichier (sans le contenu des fichiers)
• Les informations provenant du fichier CODEOWNERS

Lorsque vous créez un dashboard ou un notebook, vous pouvez utiliser des données de tests CI dans votre requête de recherche, qui modifient les options des widgets de visualisation. Pour en savoir plus, consultez la documentation relative aux Dashboards et aux Notebooks.

Alerte sur les données de tests

Lorsque vous évaluez des tests échoués ou irréguliers, ou les performances d’un test CI, vous pouvez exporter votre requête de recherche dans le Test Visibility Explorer vers un monitor CI Test en cliquant sur l’option Export.

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles:

Découvrez les dernières versions de la livraison de logiciels (connexion à l'application requise).NOTES DE VERSION Surveiller vos pipelines CI et vos tests avec Datadog CI VisibilityBLOG Dépannage de tests de bout en bout avec CI Visibility et RUMBLOG En savoir plus sur les monitors de test CIDOCUMENTATION En savoir plus sur la Gestion des tests irréguliersDOCUMENTATION Découvrez comment instrumenter vos tests Browser avec RUMDOCUMENTATION Découvrez comment dépanner Test VisibilityDOCUMENTATION