Google Espresso oder Robotium [geschlossen]

115

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?

Androidme
quelle
19
Ich hasse es ehrlich, wenn Leute abstimmen, ohne einen Kommentar zu schreiben. Ich würde mich freuen, wenn die Person, die abstimmt, einige Kommentare dazu schreibt, warum sie das tut
Androidme
8
Ich finde die Frage sehr hilfreich. Viele Entwickler fragen sich das. Was sind die Unterschiede? Ich denke, das Problem ist die Art und Weise, wie Sie fragen. Sie sollten es genauer fragen und nicht nur fragen, welche Sie verwenden sollen.
Tasomaniac
8
Dies ist genau die Frage, die ich beantworten wollte. Vielen Dank für die Veröffentlichung
Richard Fung
8
Ich mag die Tatsache nicht, dass dies laut StackOverflow nicht zum Thema gehört. Ich weiß, wenn wir jede einzelne Bibliothek und jedes Tool vergleichen müssten, könnte es viele meinungsbasierte Antworten geben, aber eine Frage wie diese, die nach den Unterschieden zwischen zwei Ressourcen fragt, ist sehr hilfreich.
David Argyle Thacker

Antworten:

175

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.

ValeraZakharov
quelle
Hallo ! Vielen Dank für Ihre Antwort. Bietet Espresso die Möglichkeit, mehrere Anwendungen im selben Testfall zu testen? Ich muss meine Anwendung testen, die eine Aktivität von einer anderen Anwendung aufruft (meine andere App, die dieselbe sharedUserId verwendet), und dann das Ergebnis abrufen. Ich kann das nicht mit Robotium machen, aber vielleicht mit Espresso? :-)
nbe_42
1
Nein - Sie können außerhalb Ihres Prozesses mit Espresso nicht mit der Benutzeroberfläche interagieren. Dies ist eine Einschränkung des Instrumentierungsrahmens.
ValeraZakharov
1
@ValeraZakharov :: Hii ... !! Wie Sie sagten, kümmert sich Espresso um die UI-Thread-Synchronisation und es ist nicht erforderlich, Sleeps zu aktivieren. In meinem Fall habe ich jedoch nur wenige Testfälle geschrieben und alle Testfälle funktionieren auf meinem lokalen Computer (mit einem Ruhezustand pro TestSuite als Start). Aber fast 99% der Testfälle schlagen fehl, wenn ich mit lokalen / Server-Jenkins laufe. Ich habe alle Animationen im Jenkins-Emulator deaktiviert. Die meiste Zeit bekomme ich AppNotIdleException. Ich bin nicht in der Lage, die Grundursache herauszufinden. Kannst du mir bitte helfen?
Naresh Gunda
@ Radu Habe es geschafft. Ihr Kommentar ist null und scheint ohne richtige Erklärung ein tollkühner Versuch zu sein, Aufmerksamkeit zu erregen.
Rakib
9

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.

Snicolas
quelle
Eine Gegenstimme würde mir helfen, ein Synonym für dieses Tag zu erstellen ..;)
Snicolas
2
Link oben geändert, dies ist der neue: google.github.io/android-testing-support-library/docs/espresso/…
Evin1_