Google Espresso lub Robotium [zamknięte]

116

Muszę użyć narzędzia do automatycznego testowania interfejsu użytkownika i jestem zdezorientowany między używaniem Robotium a Google Espresso.

Jakie są główne różnice między nimi? Czy są funkcje, które istnieją w jednej, a nie w drugiej?

Androidme
źródło
20
Szczerze nienawidzę, gdy ludzie głosują przeciw bez komentarza. Byłbym wdzięczny, gdyby osoba, która przegłosowała, napisała kilka komentarzy, jak to robi
Androidme
9
Myślę, że to pytanie jest bardzo pomocne. Wielu programistów zadaje to sobie pytanie. Jakie są różnice? Myślę, że problem tkwi w sposobie, w jaki pytasz. Powinieneś zapytać go bardziej szczegółowo, a nie tylko pytać, którego użyć.
tasomaniac
8
To jest dokładnie to pytanie, na które chciałem odpowiedzieć. Dzięki za wysłanie wiadomości
Richard Fung,
8
Nie podoba mi się fakt, że według StackOverflow jest to nie na temat. Wiem, że gdybyśmy musieli porównać każdą bibliotekę i narzędzie, mogłoby powstać wiele odpowiedzi opartych na opiniach, ale takie pytanie, które dotyczy różnic między dwoma zasobami, jest bardzo pomocne.
David Argyle Thacker

Odpowiedzi:

176

Pełne ujawnienie: jestem jednym z autorów Espresso.

Zarówno Espresso, jak i Robotium to platformy oparte na instrumentacji, co oznacza, że ​​używają Android Instrumentation do inspekcji i interakcji z testowanymi działaniami.

W Google zaczynaliśmy od Robotium, ponieważ było to wygodniejsze niż oprzyrządowanie magazynowe (czapki z głów przed programistami Robotium za zrobienie tego). Jednak to nie spełnia nasze zapotrzebowanie na ramy, które sprawiło, pisanie rzetelnych testów łatwy dla deweloperów.

Główne postępy w Espresso w porównaniu z Robotium:

  1. Synchronizacja. Domyślnie logika testu Instrumentacji jest uruchamiana w innym wątku (Instrumentacji) niż operacje interfejsu użytkownika (przetwarzane w wątku interfejsu użytkownika). Bez synchronizacji operacji testowych z aktualizacjami interfejsu użytkownika testy będą podatne na niestabilność - tj. Będą losowo kończyć się niepowodzeniem z powodu problemów z synchronizacją. Większość autorów testów ignoruje ten fakt, niektórzy dodają mechanizmy usypiania / ponawiania, a jeszcze mniej implementuje bardziej wyrafinowany kod bezpieczeństwa wątków. Żadne z nich nie jest idealne. Espresso dba o bezpieczeństwo wątków, płynnie synchronizując działania testowe i potwierdzenia z interfejsem użytkownika testowanej aplikacji. Robotium próbuje rozwiązać ten problem za pomocą mechanizmów usypiania / ponawiania, które są nie tylko zawodne, ale także powodują, że testy działają wolniej niż to konieczne.

  2. API. Espresso ma małe, dobrze zdefiniowane i przewidywalne API, które można dostosowywać. Mówisz frameworkowi, jak zlokalizować element interfejsu użytkownika za pomocą standardowych dopasowań hamcrest, a następnie instruujesz go, aby wykonał akcję lub sprawdził asercję na elemencie docelowym. Można to porównać z API Robotium, w którym od autora testu oczekuje się wyboru spośród ponad 30 metod klikania. Co więcej, Robotium ujawnia niebezpieczne metody, takie jak getCurrentActivity (co właściwie oznacza current?) I getView, które pozwalają na operowanie na obiektach poza głównym wątkiem (patrz punkt powyżej).

  3. Jasne informacje o awariach. Espresso stara się dostarczać obszernych informacji dotyczących debugowania w przypadku awarii. Co więcej, możesz dostosować sposób obsługi awarii przez Espresso za pomocą własnego modułu obsługi awarii. Nie próbowałem tego od jakiegoś czasu, ale poprzednie wersje Robotium cierpiały z powodu niespójnej obsługi błędów (np. Metoda clickOnView połknęłaby SecurityExceptions).

W przeciwieństwie do poprzedniej odpowiedzi, Espresso jest obsługiwane we wszystkich wersjach API ze znaczną liczbą użytkowników (patrz: http://developer.android.com/about/dashboards/index.html ). Działa na niektórych starszych wersjach, ale testowanie na nich byłoby stratą zasobów. A propos testowania ... Espresso jest testowane przy każdej zmianie przez kompleksowy zestaw testów (z pokryciem ponad 95%), a także większość aplikacji na Androida stworzonych przez Google.

ValeraZakharov
źródło
Cześć ! Dziękuję za odpowiedź, czy Espresso oferuje możliwość przetestowania kilku aplikacji w tym samym przypadku testowym? Muszę przetestować moją aplikację, która wywołuje działanie z innej aplikacji (moja inna aplikacja, która ma ten sam sharedUserId), a następnie pobiera wynik. Nie mogę tego zrobić z Robotium, ale może z Espresso? :-)
nbe_42
1
Nie - nie możesz wchodzić w interakcje z interfejsem użytkownika poza procesem z Espresso. Jest to ograniczenie struktury oprzyrządowania.
ValeraZakharov
1
@ValeraZakharov :: Hii ... !! Jak powiedziałeś, espresso zajmie się synchronizacją wątków interfejsu użytkownika i nie ma potrzeby umieszczania uśpienia. Ale w moim przypadku napisałem kilka przypadków testowych i wszystkie przypadki testowe działają na moim komputerze lokalnym (z jednym uśpieniem na TestSuite na początku). Ale prawie 99% przypadków testowych kończy się niepowodzeniem, gdy uruchamiam jenkins z lokalnego / serwera. Wyłączyłem wszystkie animacje w emulatorze Jenkinsa. Przez większość czasu otrzymuję wyjątek AppNotIdleException. Nie mogę znaleźć przyczyny źródłowej. Czy możesz mi pomóc?
Naresh Gunda
@Radu Zrobiłem to. Twój komentarz jest nieważny i bez odpowiedniego wyjaśnienia wydaje się nierozsądną próbą zwrócenia uwagi.
Rakib
9

Espresso jest znacznie szybsze niż Robotium, ale działa tylko w niektórych wersjach SDK.

Jeśli więc chcesz, aby test działał na wszystkich urządzeniach, wybierz Roboitum. Jeśli nie, idź na espresso i nie zapominaj, że jeszcze przez jakiś czas będziesz beta testerem.

Snicolas
źródło
Głos za mną pomógłby mi stworzyć synonim dla tego tagu ..;)
Snicolas
2
Powyższy link zmieniony, to jest nowy: google.github.io/android-testing-support-library/docs/espresso/…
Evin1_