Écrire un lanceur de test Tradefed

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Cette page explique comment écrire un nouveau lanceur de test dans Tradefed.

Arrière-plan

Pour en savoir plus sur la place des exécuteurs de test dans l'architecture Tradefed, consultez la section Structure d'un exécuteur de test.

Il ne s'agit pas d'une condition préalable à l'écriture d'un nouveau lanceur de tests. Les lanceurs de tests peuvent être écrits de manière isolée.

Minimum : implémenter l'interface

Pour être considéré comme un exécuteur de test Tradefed, le strict minimum consiste à implémenter Interface IRemoteTest et plus précisément la méthode run(TestInformation testInfo, ITestInvocationListener listener).

Cette méthode est celle invoquée par le harnais lors de l'utilisation du lanceur de test, semblable à un exécutable Java.

Chaque partie de cette méthode est considérée comme faisant partie de l'exécution du testeur de test.

Rapporter les résultats du testeur

La méthode run de l'interface de base permet d'accéder à un objet d'écouteur de type ITestInvocationListener. Cet objet est essentiel pour générer des rapports sur les résultats structurés du testeur de test vers le harnais.

En fournissant des résultats structurés, un outil d'exécution de test présente les propriétés suivantes :

• Fournissez une liste appropriée de tous les tests exécutés, de la durée de leur exécution et de leur état (réussite, échec ou autre).
• Métriques de rapport associées aux tests, le cas échéant (par exemple, métriques de temps d'installation)
• S'adapte à la plupart des outils d'infrastructure, tels que l'affichage des résultats et les métriques, etc.
• Généralement plus facile à déboguer, car il existe une trace plus précise du l'exécution.

Toutefois, la création de rapports sur les résultats structurés est facultative. Un exécuteur de test peut simplement vouloir évaluer l'état de l'ensemble de l'exécution comme "PASSED" (RÉUSSI) ou "FAILED" (ÉCHEC) sans aucun détail sur l'exécution réelle.

Les événements suivants peuvent être appelés sur l'écouteur pour informer le harnais de la progression actuelle des exécutions :

• testRunStarted: signaler le début d'un groupe de scénarios de test qui sont liés entre eux.
  • testStarted: avertit le début du démarrage d'un scénario de test.
  • testFailed/testIgnored : signale le changement d'état du cas de test en cours. Un cas de test sans changement d'état est considéré comme réussi.
  • testEnded : signale la fin du scénario de test.
• testRunFailed : indique que l'état global de l'exécution du groupe de cas de test est un échec. Une exécution de test peut être un succès ou un échec indépendamment des résultats des cas de test, en fonction de ce que l'exécution attendait. Par exemple, un binaire exécutant plusieurs scénarios de test peut signaler tous les scénarios de test réussite, mais avec un code de sortie d'erreur (pour toute motifs: fuite de fichiers, etc.).
• testRunEnded: informe la fin du groupe de scénarios de test.

Conserver et s'assurer que l'ordre des rappels est correct de l'outil de mise en œuvre du lanceur de test, par exemple en s'assurant que testRunEnded est appelé en cas d'exception à l'aide d'une clause finally.

Les rappels des scénarios de test (testStarted, testEnded, etc.) sont facultatifs. Un test l'exécution peut se produire sans scénario de test.

Vous remarquerez peut-être que cette structure d'événements est inspirée de la structure JUnit typique. L'objectif est de garder une approche proche de quelque chose de base que les développeurs que vous connaissez généralement.

Journaliser les rapports à partir du testeur

Si vous écrivez votre propre classe ou exécuteur de test Tradefed, vous implémenterez IRemoteTest et obtiendrez un ITestInvocationListener via la méthode run(). Cet écouteur peut être utilisé pour consigner des fichiers comme suit :

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

Tester avec un appareil

L'interface minimale ci-dessus permet d'exécuter des tests très simples, isolés et ne nécessitant aucune ressource particulière, par exemple des tests unitaires Java.

Les rédacteurs de tests qui souhaitent passer à l'étape suivante des tests d'appareil auront besoin des interfaces suivantes :

• IDeviceTest permet de recevoir l'objet ITestDevice qui représente l'appareil en cours de test et fournit l'API pour interagir avec lui.
• IBuildReceiver permet au test d'obtenir l'objet IBuildInfo créé au niveau étape du fournisseur de compilation contenant toutes les informations et les artefacts liés à la configuration de test.

Les outils d'exécution de test s'intéressent généralement à ces interfaces afin d'obtenir des artefacts liés à l'exécution, par exemple des fichiers supplémentaires, et d'obtenir l'appareil testé qui sera ciblé lors de l'exécution.

Tester avec plusieurs appareils

Tradefed permet d'exécuter des tests sur plusieurs appareils en même temps. Cela est utile lorsque vous testez des composants qui nécessitent une interaction externe, comme l'association d'un téléphone et d'une montre.

Pour écrire un outil d'exécution de test pouvant utiliser plusieurs appareils, vous devez implémenter IMultiDeviceTest, qui vous permettra de recevoir une carte de ITestDevice à IBuildInfo contenant la liste complète des représentations d'appareils et les informations de compilation associées.

Le setter de l'interface est toujours appelé avant la méthode run. Il est donc possible de supposer que la structure sera disponible lorsque run sera appelé.

Les tests connaissent leur configuration

Certaines implémentations de lanceur de test peuvent avoir besoin d'informations sur la configuration globale pour fonctionner correctement, par exemple des métadonnées sur l'appel, ou sur l'target_preparer exécutée précédemment, etc.

Pour ce faire, un lanceur de test peut accéder à l'objet IConfiguration. dont il fait partie et dans lequel il est exécuté. Pour en savoir plus, consultez la description de l'objet de configuration.

Pour l'implémentation du lanceur de test, vous devez implémenter le IConfigurationReceiver pour recevoir l'objet IConfiguration.

Exécuteur de test flexible

Les outils d'exécution de tests peuvent fournir un moyen flexible d'exécuter leurs tests s'ils ont un contrôle précis sur eux. Par exemple, un outil d'exécution de tests JUnit peut exécuter individuellement chaque test unitaire.

Cela permet à l'infrastructure et à l'exploitation plus larges de profiter de ce contrôle précis et les utilisateurs d'exécuter partiellement le lanceur de test via un filtrage.

La prise en charge du filtrage est décrite dans l'interface ITestFilterReceiver, qui permet de recevoir des ensembles de filtres include et exclude pour les tests qui doivent ou ne doivent pas s'exécuter.

Selon notre convention, un test est exécuté IFF s'il correspond à un ou plusieurs des filtres "Inclure" ET ne correspond à aucun des filtres d'exclusion. Si ce n'est pas le cas, incluez sont définis, tous les tests doivent être exécutés à condition qu'ils ne correspondent à aucun des les filtres d'exclusion.