Trade Federation utilise une abstraction appelée ITestDevice pour exécuter des tests. Cette abstraction objective l'appareil Android le plus commun:
- Il comporte un numéro de série
- Il a un état : "En ligne", "Disponible", "Récupération" ou "Non disponible".
- Il comporte une notion de fiabilité. Par exemple, si nous exécutons une commande, nous pouvons faire la distinction entre le cas où la commande n'est pas encore terminée, le cas où l'appareil n'est pas compatible avec l'exécution de commandes et le cas où l'appareil ne répond plus lors de l'exécution de la commande.
Classes d'appareils
Les trois implémentations principales de ITestDevice représentent trois cas d'utilisation courants.
Appareil physique
Il s'agit d'un matériel réel, connecté à la machine hôte TF via USB ou à l'aide de la fonctionnalité TCP d'adb. La classe TestDevice se trouve au-dessus de la bibliothèque ddmlib, qui est une interface Java d'adb. Par conséquent, tout appareil physique listé dans adb devices peut être instancié et utilisé comme TestDevice.
Émulateur
Les émulateurs sont gérés de manière spéciale par TF, car ils se trouvent dans un autre processus. Pour interagir avec un émulateur, spécifiez l'argument --emulator pour la commande. Pour en savoir plus, consultez LocalSdkBuildProvider et SdkAvdPreparer.
Aucun appareil
Supposons que vous disposiez d'un test qui n'interagit pas du tout avec un appareil. Par exemple, il peut simplement télécharger un fichier à partir d'un service et vérifier que le fichier lui-même est valide. NullDevice est un ITestDevice qui n'est qu'un bouchon. Il possède un numéro de série tel que null-device-N, et la plupart des opérations tentées ne sont pas exécutées de manière silencieuse ou génèrent une exception.