44

Zastanawiasz się, który z nich jest lepszym wyborem do pisania przypadków testowych dla aplikacji i bibliotek Androida: korzystanie z biblioteki Robolectric lub trzymanie się platformy testowania Androida. Chcę uruchomić pakiet testowy w wierszu poleceń i chcę, aby był niezależny od potrzeby konfigurowania emulatora lub zezwalania na podłączenie urządzenia do maszyny budującej. Czy ktokolwiek z was przeprowadzi analizę porównawczą obu tych elementów lub czegoś lepszego? Twoje doświadczenia będą bardzo pomocne przy podejmowaniu decyzji o lepszym rozwiązaniu.Automatyzacja przypadków testowych na urządzeniach z Androidem: biblioteka robotów vs system testów Androida

+1

To pytanie jest dość stare. Jak czytam teraz [dokumentacja] (https://developer.android.com/training/testing/index.html), wygląda na to, że podstawowa metoda testowania systemu Android jest do zrobienia. Nie są to wiersze poleceń, ale dla tych, którzy dopiero zaczynają, [oto kilka przykładów] (http://stackoverflow.com/a/43626962/3681880). – Suragch

Odpowiedz

93

używam wielopoziomowy system, gdzie wolę wcześniejszych poziomów miarę możliwości:

  1. Czyste testy jednostkowe. Staram się, aby jak najwięcej kodu było w pełni niezależne od API Androida, a następnie używać "czystych" testów jednostkowych, które mogą działać na dowolnej maszynie JVM. Testy te są najszybsze i pomaga zachować kod, który nie musi być przenośny dla konkretnego systemu Android.
  2. Testy jednostkowe obsługiwane przez Robolectric. Tam, gdzie mój kod ma tylko niewielkie zależności od interfejsów API Androida, które mogą być spełnione przez cienie Robolectric, testuję je za pomocą Robolectric. Jest trochę więcej czasu konfiguracji Robolectric w porównaniu do czystych testów, ale wciąż jest szybszy niż uruchomienie/działanie na emulatorze.
  3. Testy systemu Android. Gdzie Robolectric tego nie robi - albo dlatego, że cienie nie istnieją, albo dlatego, że w dużym stopniu korzystam z interfejsów API Androida (i dlatego chcę testować przeciwko Real Thing) - test piszę uruchamiany na emulatorze/urządzeniu z domyślne ramy.

Celem poziomów jest zachowanie jak najprostszych czynności, dzięki czemu cały pakiet jest szybszy i pomaga promować czystszy kod.

+1

Czy tworzysz wiele dedykowanych projektów testowych? – bianca

+1

Użyłem tylko dwóch projektów: jednego dla obu rodzajów testów jednostkowych (czysty i Robotium), drugi dla testów szkieletowych. –

+0

Jeszcze raz dziękuję! Czy używasz dowolnego narzędzia do pokrycia kodu? – bianca

5

pracowałem na obu, co znalazłem to: -

1) Robolectric nie obsługuje API 19, jest wzmianka w dokumencie - http://robolectric.org/eclipse-quick-start/. Jest to świetna wada.

2) Robolectric uruchomić na JVM nie na DVM. Nie możemy więc wykryć, że w tym konkretnym czasie GPS jest włączony w urządzeniu, czy nie, itd. Możemy tylko przekazać naszą wcześniej ustaloną wartość.

3) Pisanie kodu w Robolectric jest skomplikowane niż junit specjalnie dla fragmentu . Istnieje wiele złożoności i problemów.

4) Robolectric potrzebuje zewnętrznego słoika i konfiguracji, a dla testu junitowego nie potrzebujemy żadnej zewnętrznej biblioteki.

5) Robolectric jest szybszy, ponieważ działa na JVM, ale ma także wadę, nie widzimy interfejsu użytkownika na naszym urządzeniu, jaki kod ekranowy jest wykonywany .

Dla Androida lubię test jUnit.