Google Espresso lub Robotium [zamknięte]

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

W Google zaczęliśmy od używania Robotium, ponieważ było to wygodniejsze niż oprzyrządowanie giełdowe (czapki z głów dla programistów Robotium za to, że tak to zrobili). Jednak nie zaspokoiło to naszej potrzeby stworzenia frameworka, który sprawił, że pisanie było wiarygodnym testem Łatwy {[8] } dla programistów.

Największe postępy Espresso nad Robotium:

1. Synchronizacja. Domyślnie logika testowania oprzyrządowania działa w innym wątku (oprzyrządowanie) niż operacje interfejsu Użytkownika (przetwarzane w wątku interfejsu użytkownika). Bez synchronizacji operacji testowych z aktualizacjami interfejsu, testy będą podatne na łuszczenie - tzn. nie powiedzie się losowo z powodu problemów z czasem. Większość autorów testów ignoruje ten fakt, niektórzy dodają mechanizmy sleeps/retry, a jeszcze mniej zaimplementuj bardziej wyrafinowany kod bezpieczeństwa wątku. Żaden z nich nie jest idealny. Espresso dba o bezpieczeństwo wątków, płynnie synchronizując działania testowe i twierdzenia z interfejsem testowanej aplikacji. Robotium próbuje rozwiązać ten problem za pomocą mechanizmów sleep/retry, które są nie tylko zawodne, ale także powodują, że testy działają wolniej niż jest to konieczne.

2. API. Espresso ma małe, dobrze zdefiniowane i przewidywalne API, które można dostosować. Powiedz ramie jak aby zlokalizować element UI za pomocą standardowych matcherów hamcrest , a następnie polecić mu wykonanie akcji lub sprawdzenie twierdzenia na elemencie docelowym. Można to porównać z API Robotium, gdzie autor testu ma wybierać spośród ponad 30 metod kliknięć. Co więcej, Robotium ujawnia niebezpieczne metody, takie jak getCurrentActivity(co w ogóle oznacza prąd?) i getView, które pozwalają operować na obiektach spoza głównego wątku (patrz punkt powyżej).

3. Jasne informacje o awarii. Espresso stara się zapewnić bogate informacje debugowania w przypadku awarii. Ponadto możesz dostosować sposób, w jaki awarie są obsługiwane przez Espresso za pomocą własnego programu obsługi awarii. Dawno tego nie próbowałem, ale wcześniejsze 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 przez wszystkie API wersje 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. Mówiąc o testach... Espresso jest testowane na każdej zmianie przez kompleksowy zestaw testów (z ponad 95% pokryciem), a także większość aplikacji na Androida opracowanych przez Google.