Google Espresso ou Robotium
Je dois utiliser l'outil de test automatisé de l'interface utilisateur et je suis confus entre l'utilisation de Robotium vs Google Espresso.
Quelles sont les principales différences entre les deux? Y a-t-il des fonctionnalités qui existent dans l'une mais pas dans l'autre?
Divulgation complète: Je suis l'un des auteurs d'Espresso.
Espresso et Robotium sont des cadres basés sur l'instrumentation, ce qui signifie qu'ils utilisent Android Instrumentation pour inspecter et interagir avec les activités testées.
Chez Google, nous avons commencé par utiliser Robotium car c'était plus pratique que l'instrumentation d'origine (chapeau aux développeurs de Robotium pour l'avoir fait). Cependant, cela ne répondait pas à notre besoin d'un framework qui rendait l'écriture fiable les tests faciles pour les développeurs.
Les avancées majeures d'Espresso par rapport à Robotium:
Synchronisation. Par défaut, la logique de test d'instrumentation s'exécute sur un thread (d'instrumentation) différent des opérations d'interface utilisateur (traitées sur le thread d'interface utilisateur). Sans synchronisation des opérations de test avec les mises à jour de l'interface utilisateur, les tests seront sujets à la fragilité - c'est-à-dire qu'ils échoueront au hasard en raison de problèmes de synchronisation. La plupart des auteurs de tests ignorent ce fait, certains ajoutent des mécanismes de veille/nouvelle tentative et encore moins mettent en œuvre un code de sécurité des threads plus sophistiqué. Rien de tout cela n'est idéal. Espresso prend soin de la sécurité des threads en synchronisant de manière transparente les actions de test et les assertions avec l'interface utilisateur de l'application testée. Robotium tente de résoudre ce problème avec des mécanismes de veille/relance, qui sont non seulement peu fiables, mais provoquent également des tests plus lents que nécessaire.
API. Espresso possède une petite API bien définie et prévisible, ouverte à la personnalisation. Vous expliquez au framework comment localiser un élément d'interface utilisateur à l'aide de la norme hamcrest matchers , puis lui demandez d'effectuer une action ou de vérifier une assertion sur l'élément cible. Vous pouvez comparer cela à l'API de Robotium, où l'auteur du test est censé choisir parmi plus de 30 méthodes de clic. De plus, Robotium expose des méthodes dangereuses comme getCurrentActivity (qu'est-ce que le courant signifie de toute façon?) Et getView, qui vous permettent d'opérer sur des objets en dehors du thread principal (voir le point ci-dessus).
Effacer les informations d'échec. Espresso s'efforce de fournir des informations de débogage riches en cas d'échec. De plus, vous pouvez personnaliser la façon dont les défaillances sont gérées par Espresso avec votre propre gestionnaire de défaillance. Je ne l'ai pas essayé depuis un moment, mais les versions précédentes de Robotium souffraient d'une gestion des échecs incohérente (par exemple, la méthode clickOnView avalerait les exceptions de sécurité).
Contrairement à une réponse précédente, Espresso est pris en charge sur toutes les versions d'API avec un nombre important d'utilisateurs (voir: http://developer.Android.com/about/dashboards/index.html ). Il fonctionne sur certaines des anciennes versions, mais les tester serait un gaspillage de ressources. Parlant de tests ... Espresso est testé à chaque changement par une suite de tests complète (avec une couverture de plus de 95%) ainsi que la majorité des applications Android développées par Google).
Espresso est beaucoup plus rapide que Robotium, mais ne fonctionne que sur certaines versions du SDK.
Donc, si vous voulez un test qui fonctionne sur tous les appareils, optez pour Roboitum. Sinon, optez pour l'espresso et n'oubliez pas que vous serez un bêta-testeur pendant encore un certain temps.