Google Espresso lub Robotium [zamknięte]

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?

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.

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.