Google Espresso ou Robotium

Question

Je dois utiliser un outil de test automatisé de l'interface utilisateur et je ne sais pas s'il faut utiliser Robotium ou Google Espresso. Toute suggestion serait utile.

Answer 1

Divulgation complète : je suis l'un des auteurs d'Espresso.

Espresso et Robotium sont tous deux des frameworks basés sur l'instrumentation, ce qui signifie qu'ils utilisent Instrumentation Android pour inspecter et interagir avec les activités en cours de test.

Chez Google, nous avons commencé par utiliser Robotium parce qu'il était plus pratique que l'instrumentation stockée (chapeau bas aux développeurs de Robotium qui l'ont rendu ainsi). Cependant, cela ne répondait pas à notre besoin d'un cadre de travail qui rende l'écriture de données plus facile. fiable tests facile pour les développeurs.

Les principales avancées d'Espresso par rapport à Robotium :

1. Synchronisation. Par défaut, la logique de test d'instrumentation s'exécute sur un thread (d'instrumentation) différent des opérations de l'interface utilisateur (traitées sur le thread de l'interface utilisateur). Sans synchronisation des opérations de test avec les mises à jour de l'interface utilisateur, les tests seront sujets à la volatilité, c'est-à-dire qu'ils échoueront de manière aléatoire en raison de problèmes de timing. La plupart des auteurs de tests ignorent ce fait, certains ajoutent des mécanismes de sommeil/répétition et encore moins implémentent un code de sécurité thread plus sophistiqué. Aucune de ces solutions n'est idéale. Espresso prend en charge la sécurité des threads en synchronisant de manière transparente les actions et les assertions de test avec l'interface utilisateur de l'application testée. Robotium tente de résoudre ce problème avec des mécanismes de sommeil/répétition, qui non seulement ne sont pas fiables, mais qui ralentissent également l'exécution des tests.

2. API. Espresso dispose d'une petite API, bien définie et prévisible, qui est ouverte à la personnalisation. Vous indiquez au framework comment localiser un élément de l'interface utilisateur à l'aide de la fonction standard matchers de hamcrest et lui demander d'effectuer une action ou de vérifier une assertion sur l'élément cible. Vous pouvez comparer cela avec l'API de Robotium, où l'auteur du test doit choisir parmi plus de 30 méthodes de clic. En outre, Robotium expose des méthodes dangereuses telles que getCurrentActivity (que signifie current, d'ailleurs ?) et getView, qui vous permettent d'agir sur des objets en dehors du thread principal (voir le point ci-dessus).

3. Une information claire sur les défaillances. Espresso s'efforce de fournir de nombreuses informations de débogage lorsqu'une panne survient. De plus, vous pouvez personnaliser la façon dont les échecs sont traités par Espresso avec votre propre gestionnaire d'échec. Je n'ai pas essayé depuis longtemps, mais les versions précédentes de Robotium souffraient d'un traitement incohérent des échecs (par exemple, la méthode clickOnView avalait les SecurityExceptions).

Contrairement à une réponse précédente, Espresso est supporté sur toutes les versions de l'API avec un nombre significatif 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. En 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.

Answer 2

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 espresso, et n'oubliez pas que vous serez un bêta-testeur pendant encore un certain temps.