Écrire un exécuteur de test Tradefed

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

Arrière-plan

Si vous êtes curieux de connaître la place des lanceurs de test dans l'architecture Tradefed, consultez la page Structure d'un exécuteur de test.

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

Au 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 lanceur de test.

Rapporter les résultats du lanceur de test

La méthode run de l'interface de base permet d'accéder à un objet écouteur de saisissez ITestInvocationListener. Cet objet est la clé pour créer des rapports les résultats du coureur d'essai au harnais.

Lorsqu'il signale des résultats structurés, un lanceur de test possède les propriétés suivantes:

  • Fournir une liste correcte de tous les tests qui ont été exécutés, leur durée et si qu'ils ont réussi ou échoué individuellement ou d'autres états.
  • Créer des rapports sur les métriques associées aux tests, le cas échéant (par exemple, 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 lanceur de test pourrait simplement évaluer l'état de l'intégralité de l'exécution comme RÉUSSITE ou ÉCHEC sans les détails de l'exécution réelle.

Les événements suivants peuvent être appelés sur l'écouteur pour avertir l'exploitant du 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: signaler le changement d'état du scénario de test en cours. Un scénario type sans changement d'état est considéré comme réussi.
    • testEnded: signaler la fin du scénario de test.
  • testRunFailed: signaler que l'état général du groupe de scénarios de test est un échec. L'exécution d'un test peut être une réussite ou un échec. indépendamment des résultats des scénarios de test, en fonction l’exécution attendue. 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 s'inspire de structure JUnit type. L'objectif est de garder une approche proche de quelque chose de base que les développeurs que vous connaissez généralement.

Enregistrer les journaux du lanceur de test

Si vous écrivez votre propre classe de test ou exécuteur Tradefed, vous allez implémenter IRemoteTest et d'obtenir un ITestInvocationListener via la méthode run(). Cet écouteur peut être utilisé pour les fichiers journaux, 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 qui sont isolés et ne nécessitent aucune ressource particulière, comme les tests unitaires Java.

Les rédacteurs de tests qui souhaitent passer à l'étape suivante des tests des appareils doivent disposer des les interfaces suivantes:

  • IDeviceTest permet de recevoir l'objet ITestDevice qui représente l'appareil sous et fournit l'API pour interagir avec elle.
  • 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 exécuteurs de test s'intéressent généralement à ces interfaces pour obtenir liés à l'exécution (fichiers supplémentaires, par exemple), puis obtenez l'appareil testé et qui sera ciblé pendant l'exécution.

Tester avec plusieurs appareils

Tradefed permet d'exécuter des tests sur plusieurs appareils en même temps. C'est utiles pour tester des composants qui nécessitent une interaction externe, comme association entre un téléphone et une montre.

Pour écrire un lanceur de test pouvant utiliser plusieurs appareils, vous aurez besoin pour mettre en œuvre IMultiDeviceTest, qui permettra de recevoir un mappage de ITestDevice à IBuildInfo contenant la liste complète des représentations de l'appareil et les informations de compilation associées.

Le setter de l'interface sera toujours appelé avant la méthode run. Par conséquent, vous pouvez supposer que la structure sera disponible lorsque run sera appelé.

Les tests connaissent leur configuration

Certaines implémentations de lanceurs de test peuvent nécessiter des informations sur la configuration globale. pour fonctionner correctement, par exemple des métadonnées sur l'appel, ou exécuté précédemment par target_preparer, 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é. Consultez le objet de configuration pour en savoir plus.

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 lanceurs de tests peuvent fournir un moyen flexible d'exécuter leurs tests s'ils ont un un contrôle granulaire ; par exemple, un exécuteur de tests JUnit peut individuellement exécuter 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 la Interface ITestFilterReceiver, qui permet de recevoir des ensembles de filtres include et exclude pour les tests qui doit être exécuté ou non.

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.