Google Espresso oder Robotium [geschlossen]

Ich muss das Test-Tool für die automatisierte Benutzeroberfläche verwenden und bin verwirrt zwischen der Verwendung von Robotium und Google Espresso.

Was sind die Hauptunterschiede zwischen den beiden? Gibt es Funktionen, die in der einen, aber nicht in der anderen vorhanden sind?

Vollständige Offenlegung: Ich bin einer der Autoren von Espresso.

Sowohl Espresso als auch Robotium sind instrumentationsbasierte Frameworks, dh sie verwenden Android Instrumentation , um die getesteten Aktivitäten zu überprüfen und mit ihnen zu interagieren.

Bei Google haben wir zunächst Robotium verwendet, weil es bequemer war als die Standardinstrumentierung (Hut ab vor Robotium-Entwicklern dafür). Es entsprach jedoch nicht unserem Bedarf an einem Framework, das Entwicklern das Schreiben zuverlässiger Tests erleichtert .

Die wichtigsten Fortschritte bei Espresso gegenüber Robotium:

1. Synchronisation. Standardmäßig wird die Instrumentierungstestlogik auf einem anderen (Instrumentierungs-) Thread als UI-Operationen ausgeführt (auf dem UI-Thread verarbeitet). Ohne die Synchronisierung von Testvorgängen mit UI-Updates sind die Tests anfällig für Flakiness - dh sie schlagen aufgrund von Zeitproblemen zufällig fehl. Die meisten Testautoren ignorieren diese Tatsache, einige fügen Schlaf- / Wiederholungsmechanismen hinzu und noch weniger implementieren komplexeren Thread-Sicherheitscode. Keines davon ist ideal. Espresso sorgt für die Thread-Sicherheit, indem Testaktionen und Zusicherungen nahtlos mit der Benutzeroberfläche der zu testenden Anwendung synchronisiert werden. Robotium versucht, dies mit Schlaf- / Wiederholungsmechanismen zu beheben, die nicht nur unzuverlässig sind, sondern auch dazu führen, dass Tests langsamer als nötig ablaufen.

2. API. Espresso verfügt über eine kleine, genau definierte und vorhersehbare API, die angepasst werden kann. Sie teilen dem Framework mit, wie ein UI-Element mithilfe von Standard- Hamcrest-Matchern gefunden werden soll, und weisen es dann an, entweder eine Aktion auszuführen oder eine Zusicherung für das Zielelement zu überprüfen. Sie können dies mit der Robotium-API vergleichen, bei der der Testautor aus mehr als 30 Klickmethoden auswählen soll. Darüber hinaus stellt Robotium gefährliche Methoden wie getCurrentActivity (was bedeutet aktuell überhaupt?) Und getView zur Verfügung, mit denen Sie Objekte außerhalb des Hauptthreads bearbeiten können (siehe Punkt oben).

3. Fehlerinformationen löschen. Espresso ist bestrebt, bei einem Fehler umfangreiche Debugging-Informationen bereitzustellen. Darüber hinaus können Sie die Art und Weise, wie Fehler von Espresso behandelt werden, mit Ihrem eigenen Fehlerbehandler anpassen. Ich habe es eine Weile nicht mehr versucht, aber frühere Versionen von Robotium litten unter einer inkonsistenten Fehlerbehandlung (z. B. würde die clickOnView-Methode SecurityExceptions verschlucken).

Im Gegensatz zu einer früheren Antwort wird Espresso auf allen API-Versionen mit einer erheblichen Anzahl von Benutzern unterstützt (siehe: http://developer.android.com/about/dashboards/index.html ). Es funktioniert bei einigen älteren Versionen, aber das Testen dieser Versionen wäre eine Verschwendung von Ressourcen. Apropos Testen ... Espresso wird bei jeder Änderung von einer umfassenden Testsuite (mit über 95% Abdeckung) sowie den meisten von Google entwickelten Android-Anwendungen getestet.

Espresso ist viel schneller als Robotium, funktioniert aber nur bei einigen SDK-Versionen.

Wenn Sie also einen Test wünschen, der auf allen Geräten funktioniert, entscheiden Sie sich für Roboitum. Wenn nicht, nehmen Sie Espresso und vergessen Sie nicht, dass Sie noch einige Zeit Beta-Tester sind.