Cycle de vie des tests TF

Le cycle de vie d'un test exécuté à l'aide de Trade Federation est composé de quatre étapes distinctes, conçues autour d'interfaces formellement définies.

Interfaces définies

  • Fournisseur de build : fournit une build à tester, en téléchargeant les fichiers appropriés si nécessaire.
  • Target Preparer : prépare l'environnement de test, y compris éventuellement l'installation du logiciel et la configuration de l'appareil.
  • Test : exécute les tests et recueille les résultats des tests. Il peut s'agir de n'importe quel test JUnit, bien que notre interface IRemoteTest soit spécifiquement conçue pour fonctionner correctement dans l'environnement de la fédération commerciale.
  • Test Invocation Listener (rapport de résultats) : écoute les résultats de test, généralement dans le but de transmettre les résultats de test à un référentiel ou de les afficher au Test Runner.

L'entité de test fondamentale dans TF est une configuration (config). Une configuration est un fichier XML qui déclare les composants du cycle de vie d'un test.

Cette séparation du cycle de vie du test est destinée à permettre une réutilisation. En utilisant cette conception, le développeur peut créer un test une fois, puis l'intégrateur peut créer différentes configurations pour exécuter ce test dans différents environnements. Par exemple, ils peuvent créer une configuration qui exécutera un test sur une machine locale et videra le résultat dans stdout. Ils pourraient ensuite créer une deuxième configuration qui exécuterait ce même test, mais utiliserait un autre écouteur d'invocation de test pour stocker les résultats du test dans une base de données. Une troisième configuration peut être conçue pour exécuter ce test en continu à partir d'un laboratoire de test quelque part.

Il est pratique de noter ici qu'une configuration avec ses arguments de ligne de commande (tels que fournis par le Test Runner) est connue sous le nom de commande . Lorsque TF associe une commande à un ITestDevice et l'exécute, l'objet suivant est appelé invocation . En bref, une invocation englobe une exécution de test TF complète, tout au long de son cycle de vie.

Composants de configuration supplémentaires

Sortie d'étape et erreurs

Chaque étape d'un appel s'exécute séquentiellement et a un objectif spécifique. Cette section décrit les résultats et les erreurs habituels de chaque étape.

Construire le fournisseur

Cette étape crée et génère un objet IBuildInfo qui contient toutes les références de fichiers requises pour configurer et exécuter les tests.

L'erreur la plus courante à ce stade est l'échec du téléchargement ou de la recherche des fichiers demandés.

Une erreur à ce stade entraîne le signalement direct de l'erreur et aucun test n'est exécuté.

Préparation de la cible

Cette étape met en place les états nécessaires pour la cible sous test. Cette étape peut modifier le périphérique ou la configuration de l'hôte selon les besoins pour l'appel de test donné.

Les erreurs courantes à ce stade impliquent généralement l'échec de la configuration du périphérique dans un état donné (par exemple, l'échec du clignotement) et l'échec de la recherche des fichiers requis pour la configuration.

Une erreur à ce stade entraîne l'exécution du nettoyage de la cible, le signalement de l'erreur et aucun test n'est exécuté.

Des tests

Cette étape exécute les tests demandés sur la cible préalablement préparée et rapporte tous les résultats de l'exécution des tests.

Les erreurs courantes à ce stade impliquent généralement que la cible testée soit indisponible ou qu'une erreur entraîne une exécution partielle des tests. Ces erreurs sont des problèmes d'infrastructure qui affectent l'exécution du test elle-même, par opposition à l'échec d'un seul scénario de test.

Une erreur à ce stade entraîne l'arrêt de l'exécution du test, l'exécution du nettoyage de la cible, le signalement de l'erreur et l'obtention de résultats partiels.

Reporting des résultats

Cette étape rapporte les résultats et les erreurs aux services configurés (par exemple, les serveurs et les fichiers locaux).

Bien que les rapporteurs de résultats individuels puissent avoir des erreurs, ils sont isolés les uns des autres (un journaliste ne voit pas les erreurs d'un autre). Ces erreurs n'affectent que le rapport des résultats d'un déclarant individuel et les erreurs peuvent être visualisées dans les journaux.