Ce produit n'est pas pris en charge par le site Datadog que vous avez sélectionné. ().
Essayez les premiers pas avec l'optimisation des tests dans le Centre d'apprentissage
Apprenez à accélérer vos pipelines CI en configurant la surveillance des tests, en identifiant les tests instables et en utilisant l'analyse d'impact des tests pour exécuter uniquement les tests qui comptent.
L’optimisation des tests fournit une vue axée sur les tests de la santé de votre CI en affichant des métriques et des résultats importants de vos tests. Cela peut vous aider à enquêter sur les problèmes de performance et les échecs de tests qui sont les plus pertinents pour votre travail, en vous concentrant sur le code dont vous êtes responsable, plutôt que sur les pipelines qui exécutent vos tests.
Configuration
Sélectionnez une option pour configurer l’optimisation des tests dans Datadog :
En plus des tests, l’optimisation des tests offre une visibilité sur l’ensemble de la phase de test de votre projet.
Fonctionnalités prises en charge
.NET
Java/JVM‑basé
Javascript
Python
Ruby
Swift
Go
JUnit Xml
Résultats précis des temps/durées
Résolution en microsecondes pour le temps de début et la durée des tests.
Traces distribuées sur les tests d'intégration
Les tests qui effectuent des appels à des services externes instrumentés avec Datadog montrent la trace distribuée complète dans les détails de leur test.
Rapport basé sur un agent
Capacité à rapporter des informations de test via l'Agent Datadog.
Rapport sans agent
Capacité à rapporter des informations de test sans l'Agent Datadog.
Affichage au niveau des collections de tests
Visibilité sur l'ensemble du processus de test, y compris la session, le module, les suites et les tests.
API manuelle
Capacité à créer de manière programmatique des événements de visibilité CI pour des frameworks de test qui ne sont pas pris en charge par l'instrumentation automatique de Datadog.
Propriétaire de code par test
Détection automatique du propriétaire d'un fichier de test basé sur le fichier CODEOWNERS.
(partiellement)
Début/fin du code source
Rapport automatique des lignes de début et de fin d'un test.
(seulement début)
(seulement début)
Informations CI et git
Collecte automatique des métadonnées de l'environnement git et CI, telles que le fournisseur CI, le SHA du commit git ou l'URL du pipeline.
Les tests évaluent le comportement du code pour un ensemble de conditions données. Certaines de ces conditions sont liées à l’environnement dans lequel les tests sont exécutés, comme le système d’exploitation ou l’environnement d’exécution utilisé. Le même code exécuté sous différents ensembles de conditions peut se comporter différemment, donc les développeurs configurent généralement leurs tests pour s’exécuter dans différents ensembles de conditions et valident que le comportement est celui attendu pour tous. Cet ensemble spécifique de conditions est appelé une configuration.
Dans l’optimisation des tests, un test avec plusieurs configurations est traité comme plusieurs tests avec un test séparé pour chaque configuration. Dans le cas où l’une des configurations échoue mais que les autres réussissent, seul ce test spécifique et cette combinaison de configuration sont marqués comme échoués.
Par exemple, supposons que vous testiez un seul commit et que vous ayez un test Python qui s’exécute contre trois versions différentes de Python. Si le test échoue pour l’une de ces versions, ce test spécifique est marqué comme échoué, tandis que les autres versions sont marquées comme réussies. Si vous réessayez les tests contre le même commit et que maintenant le test pour les trois versions de Python réussit, le test avec la version qui avait échoué est maintenant marqué comme réussi et instable, tandis que les deux autres versions restent réussies, sans instabilité détectée.
Attributs de configuration des tests
Lorsque vous exécutez vos tests avec l’optimisation des tests, la bibliothèque détecte et rapporte des informations sur l’environnement dans lequel les tests sont exécutés sous forme d’étiquettes de test. Par exemple, le nom du système d’exploitation, tel que Windows ou Linux, et l’architecture de la plateforme, telle que arm64 ou x86_64, sont ajoutés comme étiquettes à chaque test. Ces valeurs sont affichées dans le commit et sur les pages de vue d’ensemble des branches lorsqu’un test échoue ou est instable pour une configuration spécifique mais pas pour d’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 :
Nom de l’étiquette
Description
os.platform
Nom du système d’exploitation où les tests sont exécutés.
os.family
Famille du système d’exploitation où les tests sont exécutés.
os.version
Version du système d’exploitation où les tests sont exécutés.
os.architecture
Architecture du système d’exploitation où les tests sont exécutés.
runtime.name
Nom du système d’exécution pour les tests.
runtime.version
Version du système d’exécution.
runtime.vendor
Fournisseur qui a construit la plateforme d’exécution où les tests sont exécutés.
runtime.architecture
Architecture du système d’exécution pour les tests.
device.model
Le modèle de l’appareil exécutant les tests.
device.name
Nom de l’appareil.
ui.appearance
Style de l’interface utilisateur.
ui.orientation
Orientation dans laquelle l’interface utilisateur est exécutée.
ui.localization
Langue de l’application.
Configurations de test paramétrées
Lorsque vous exécutez des tests paramétrés, la bibliothèque détecte et rapporte des informations sur les paramètres utilisés. Les paramètres font partie de la configuration des tests, donc le même cas de test exécuté avec des paramètres différents est considéré comme deux tests différents dans l’optimisation des tests.
Si un paramètre de test est non déterministe et a une valeur différente chaque fois qu’un test est exécuté, chaque exécution de test est considérée comme un nouveau test dans l’optimisation des tests. En conséquence, certaines fonctionnalités du produit peuvent ne pas fonctionner correctement pour de tels tests : historique des exécutions, détection de l’instabilité, analyse de l’impact des tests, et d’autres.
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 d’exécution du test (comme un chemin de fichier absolu ou le nom d’utilisateur actuel)
une valeur qui n’a 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 redéfinie)
Évitez d’utiliser des paramètres de test non déterministes. Dans le cas où cela n’est pas possible, certains frameworks de test offrent un moyen de spécifier une représentation de chaîne déterministe pour un paramètre non déterministe (comme le fait de remplacer le nom d’affichage du paramètre).
Configurations personnalisées
Il existe certaines configurations qui ne peuvent pas être identifiées et rapportées automatiquement car elles peuvent dépendre de variables d’environnement, d’arguments d’exécution de test ou d’autres approches utilisées par les développeurs. Pour ces cas, vous devez fournir les détails de configuration à la bibliothèque afin que l’optimisation des tests puisse les identifier correctement.
Définissez ces balises comme partie de la variable d’environnement DD_TAGS en utilisant le 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 :
Intégrez l'optimisation des tests avec des outils pour rapporter des données de couverture de code, améliorez les tests de navigateur avec RUM et accédez à des informations à travers les plateformes en rationalisant l'identification et la résolution des problèmes dans votre cycle de développement.
When Test Visibility is enabled, the following data is collected from your project:
Test names and durations.
Predefined environment variables set by CI providers.
Git commit history including the hash, message, author information, and files changed (without file contents).
Information from the CODEOWNERS file.
Lors de la création d’un Dashboard ou d’un Notebooks, vous pouvez utiliser les données des tests CI dans votre requête de recherche, ce qui met à jour les options du widget de visualisation. Pour plus d’informations, consultez la documentation des Dashboards et des Notebooks documentation.
Activez les alertes sur les données de test
Lorsque vous évaluez des tests échoués ou instables, ou la performance d’un test CI, vous pouvez exporter votre requête de recherche dans le Test Optimization Explorer vers un CI Test monitor en cliquant sur le bouton Exporter.
Lectures complémentaires
Documentation, liens et articles supplémentaires utiles:
