Testowanie z poziomu wiersza poleceń

W tym dokumencie opisano, jak przeprowadzać testy bezpośrednio z poziomu wiersza poleceń. W tym dokumencie zakładamy, że wiesz już, jak utworzyć aplikację na Androida i pisać testy aplikacji. Więcej informacji o tworzeniu testów aplikacji znajdziesz w artykule Testowanie aplikacji na Androidzie.

Gdy tworzysz aplikację za pomocą systemu kompilacji Gradle, wtyczka Androida do obsługi Gradle umożliwia przeprowadzanie testów z projektu Gradle za pomocą wiersza poleceń. Aby mieć bardziej precyzyjną kontrolę, możesz przeprowadzać testy z użyciem powłoki Android Debug Bridge (adb). Jest to przydatne podczas przeprowadzania testów w środowisku ciągłej integracji.

Aby dowiedzieć się, jak przeprowadzać zautomatyzowane testy instrumentalne z poziomu wiersza poleceń, na urządzeniach wirtualnych, którymi zarządza Gradle, przeczytaj artykuł o skalowaniu testów przy użyciu urządzeń zarządzanych przez Gradle.

Uruchamianie testów za pomocą Gradle

Wtyczka Androida do obsługi Gradle umożliwia przeprowadzanie testów z projektu Gradle za pomocą wiersza poleceń.

Tabela poniżej zawiera podsumowanie sposobu przeprowadzania testów za pomocą Gradle:

Tabela 1. Różne sposoby przeprowadzania testów za pomocą Gradle

Typ testu jednostkowego Polecenie do uruchomienia Lokalizacja wyniku testu
Test z użyciem jednostki lokalnej Uruchom zadanie test: 

./gradlew test
Pliki wyników testu HTML:
katalog path_to_your_project/module_name/build/reports/tests/.

Pliki wyników testu XML:
katalog path_to_your_project/module_name/build/test-results/.

Instrumentalny test jednostkowy Uruchom zadanie connectedAndroidTest: 

./gradlew connectedAndroidTest
Pliki wyników testu HTML:
katalog path_to_your_project/module_name/build/reports/androidTests/connected/.

Pliki wyników testu XML:
katalog path_to_your_project/module_name/build/outputs/androidTest-results/connected/.

Gradle obsługuje skróty nazw zadań. Możesz na przykład uruchomić zadanie connectedAndroidTest, wpisując to polecenie:

./gradlew cAT

Możesz też uruchomić zadania Gradle check i connectedCheck. Te zadania uruchamiają odpowiednio testy lokalne lub instrumentowane, ale obejmują też inne testy dodane przez inne wtyczki Gradle.

Przeprowadzanie testów modułu

Zadania test i connectedAndroidTest uruchamiają testy w każdym module w projekcie. Aby uruchomić testy konkretnego modułu, dodaj zadanie test lub connectedAndroidTest do nazwy modułu i dwukropka (:). Na przykład to polecenie uruchamia testy instrumentowane tylko dla modułu mylibrary:

./gradlew mylibrary:connectedAndroidTest

Przeprowadzanie testów na wariancie kompilacji

Zadania test i connectedAndroidTest uruchamiają testy każdego wariantu kompilacji w projekcie. Możesz ustawić kierowanie na konkretny wariant kompilacji, używając tej składni:

  • W przypadku testów w jednostkach lokalnych: 
    ./gradlew testVariantNameUnitTest
  • W przypadku testów instrumentalnych:
    ./gradlew connectedVariantNameAndroidTest

Uruchamiaj określone metody lub klasy testowe

Podczas testów jednostkowych Gradle umożliwia kierowanie określonych testów za pomocą flagi --tests. Na przykład to polecenie uruchamia tylko testy sampleTestMethod dla określonego wariantu kompilacji. Więcej informacji o używaniu flagi --tests znajdziesz w dokumentacji Gradle dotyczącej filtrowania testów.


./gradlew testVariantNameUnitTest --tests '*.sampleTestMethod'

Raporty z większą liczbą modułów na potrzeby testów z instrumentacją

Zgodnie z opisem w tabeli 1 Gradle zapisuje wyniki z instrumentowanych testów w katalogu build/ każdego testowanego modułu. Jednak gdy przeprowadzasz testy w wielu modułach, przydatne może być połączenie wszystkich wyników testu w jednym raporcie. Aby wygenerować jeden raport podczas testów w wielu modułach, wykonaj te czynności:

  1. W pliku build.gradle na poziomie projektu dodaj ten fragment po bloku buildscript{}:

    Odlotowy

    apply plugin: 'android-reporting'

    Kotlin

    apply(plugin = "android-reporting")

  2. Wywołaj zadanie test lub connectedAndroidTest za pomocą zadania mergeAndroidReports. Na przykład:

    ./gradlew connectedAndroidTest mergeAndroidReports

    Aby pominąć błędy testów i umożliwić Gradle zakończenie wszystkich pozostałych testów, dodaj opcję --continue:

    ./gradlew connectedAndroidTest mergeAndroidReports --continue

Gdy Gradle zakończy testowanie testów, zapisze połączone wyniki w katalogu path_to_your_project/build/.

Przeprowadzanie testów z użyciem narzędzia adb

Jeśli przeprowadzasz testy z poziomu wiersza poleceń przy użyciu narzędzia Android Debug Bridge (adb), masz do wyboru więcej opcji niż w przypadku jakichkolwiek innych metod. Można wybrać poszczególne metody testowania, filtrować testy według niestandardowej adnotacji lub określić opcje testowania. Test jest sterowany w całości z poziomu wiersza poleceń, dlatego możesz dostosowywać testowanie za pomocą skryptów powłoki na różne sposoby.

Aby uruchomić test z poziomu wiersza poleceń, uruchom polecenie adb shell w celu uruchomienia powłoki wiersza poleceń na urządzeniu lub emulatorze. W tej powłoce możesz korzystać z menedżera aktywności za pomocą polecenia am i jego podpolecenia instrument do uruchamiania testów.

Jako skrót możesz uruchomić powłokę adb, wywołać funkcję am instrument i określić flagi wiersza poleceń w jednym wierszu wejściowym. Powłoka otwiera się na urządzeniu lub emulatorze, uruchamia testy, generuje dane wyjściowe, a potem wraca do wiersza poleceń na komputerze.

Aby przeprowadzić test w narzędziu am instrument:

  1. Skompiluj lub ponownie skompiluj aplikację główną i pakiet testowy.
  2. Zainstaluj pakiet testowy i główne pliki pakietów aplikacji na Androida (pliki APK) na obecnym urządzeniu z Androidem lub w emulatorze.

  3. W wierszu poleceń wpisz:

    adb shell am instrument -w <test_package_name>/<runner_class>

    Gdzie <test_package_name> to nazwa pakietu na Androida aplikacji testowej, a <runner_class> to nazwa klasy uruchamiania testów Androida, której używasz. Nazwa pakietu na Androida jest wartością atrybutu pakietu elementu manifestu w pliku manifestu pakietu testowego (AndroidManifest.xml).

    Klasa Android Test Runner to zwykle AndroidJUnitRunner:

    adb shell am instrument -w com.android.example/androidx.test.runner.AndroidJUnitRunner

Wyniki testu wyświetlą się w tym języku: STDOUT.

flagi am instrumentów

Aby znaleźć listę wszystkich flag do użycia w poleceniu am instrument, uruchom adb shell am help. Kilka ważnych flag znajdziesz w tej tabeli:

Tabela 2. Ważne flagi am instrument

Zgłoś Wartość Opis
-w (brak) Wymusza, aby am instrument oczekiwał na zakończenie instrumentacji, zanim się zakończy. Powłoka ta pozostanie otwarta, dopóki testy nie zostaną ukończone. Ta flaga jest wymagana do wyświetlania wyników testów.
-r (brak) Na wyjściu generuje nieprzetworzony wynik. Użyj tej flagi, jeśli chcesz zbierać pomiary wydajności, aby nie były sformatowane jako wyniki testu. Ta flaga jest przeznaczona do użycia z flagą -e perf true (opisaną w sekcji am instrument options).
-e <test_options> Udostępnia opcje testowania w postaci par klucz-wartość. Narzędzie am instrument przekazuje je do określonej klasy instrumentacji za pomocą metody onCreate(). Możesz określić wiele wystąpień elementu -e <test_options>. Klucze i wartości zostały opisane w sekcji Opcje instrumentu am. Tych par klucz-wartość możesz używać tylko z AndroidJUnitRunner lub InstrumentationTestRunner i jego podklasami. Użycie ich w innych klasach nie ma żadnego efektu.
--no-hidden-api-checks (brak) Wyłącza ograniczenia dotyczące korzystania z ukrytych interfejsów API. Więcej informacji o ukrytych interfejsach API i o tym, jak może to wpływać na Twoją aplikację, znajdziesz w artykule Ograniczenia dotyczące interfejsów spoza SDK.

opcje instrumentów am

Narzędzie am instrument przekazuje opcje testowania do funkcji AndroidJUnitRunner lub InstrumentationTestRunner w postaci par klucz-wartość, korzystając z flagi -e, o takiej składni:

-e <key> <value>

Niektóre klucze mogą mieć wiele wartości. Możesz podać wiele wartości na liście rozdzielonej przecinkami. Na przykład wywołanie metody AndroidJUnitRunner zwraca wiele wartości dla klucza package:

adb shell am instrument -w -e package com.android.test.package1,com.android.test.package2 \
> com.android.test/androidx.test.runner.AndroidJUnitRunner

W tabeli poniżej znajdziesz pary klucz-wartość, których możesz używać z elementem uruchamiającym test:

Tabela 3. -e flagi par klucz-wartość do użycia w programie uruchamiającym test

Klucz Wartość Opis
package <Java_package_name> Pełna nazwa pakietu Java dla jednego z pakietów w aplikacji testowej. Każda klasa przypadku testowego, która używa tej nazwy pakietu, jest wykonywana. Zwróć uwagę, że nie jest to nazwa pakietu na Androida. Pakiet testowy ma 1 nazwę pakietu na Androida, ale może zawierać kilka pakietów Javy.
class <class_name> Pełna nazwa klasy Java dla jednej z klas przypadku testowego. Tylko ta klasa przypadku testowego jest wykonywana.
<class_name>#method name Pełna nazwa klasy przypadku testowego i jedna z jej metod. Tylko ta metoda jest wykonywana. Zwróć uwagę na znak # między nazwą klasy a nazwą metody.
func true Uruchamia wszystkie klasy testowe z rozszerzeniem InstrumentationTestCase.
unit true Uruchamia wszystkie klasy testowe, które nie rozszerzają zakresu InstrumentationTestCase ani PerformanceTestCase.
size [small | medium | large] Uruchamia metodę testowania z adnotacjami dotyczącymi rozmiaru. Adnotacje to @SmallTest, @MediumTest i @LargeTest.
perf true Uruchamia wszystkie klasy testowe, które implementują PerformanceTestCase. W przypadku tej opcji podaj flagę -r dla am instrument, aby dane wyjściowe były przechowywane w nieprzetworzonym formacie i nie były przeformatowane jako wyniki testu.
debug true Przeprowadza testy w trybie debugowania.
log true Wczytuje i rejestruje wszystkie określone testy, ale ich nie uruchamia. Informacje o teście pojawią się w polu STDOUT. Służy do sprawdzania kombinacji innych filtrów i specyfikacji testu.
emma true Przeprowadza analizę zasięgu kodu EMMA i zapisuje dane wyjściowe w funkcji /data/<app_package>/coverage.ec na urządzeniu. Aby zastąpić lokalizację pliku, użyj klucza coverageFile opisanego poniżej.

Uwaga: ta opcja wymaga kompilacji aplikacji testowej obsługiwanej przez EMMA, którą można wygenerować za pomocą środowiska docelowego coverage.

coverageFile <filename> Zastępuje domyślną lokalizację pliku pokrycia EMM na urządzeniu. Podaj tę wartość jako ścieżkę i nazwę pliku w formacie UNIX. Domyślna nazwa pliku jest opisana we wpisie klucza emma.

Podczas korzystania z flagi -e pamiętaj o tych kwestiach:

  • am instrument wywołuje funkcję onCreate(Bundle) z parametrem Bundle zawierającym pary klucz-wartość.
  • Klucz package ma pierwszeństwo przed kluczem class. Jeśli określisz pakiet, a następnie oddzielnie określisz w nim klasę, Android uruchomi wszystkie testy zawarte w pakiecie i zignoruje klucz klasy.
  • Klucz func i unit wzajemnie się wykluczają.

Przykłady użycia

Poniższe sekcje zawierają przykłady użycia am instrument do uruchamiania testów. Są oparte na tej strukturze:

  • Pakiet testowy ma nazwę com.android.demo.app.tests.
  • 2 instrumentowane klasy testowe:
    • TestClass1, który zawiera metodę testowania testMethod1.
    • TestClass2, który zawiera metody testów testMethod2 i testMethod3.
  • Tester to AndroidJUnitRunner.

Uruchamianie całego pakietu testowego

Aby uruchomić wszystkie klasy testowe w pakiecie testowym, wpisz:

adb shell am instrument -w com.android.demo.app.tests/androidx.test.runner.AndroidJUnitRunner

Uruchamianie wszystkich testów w klasie przypadku testowego

Aby uruchomić wszystkie testy w zajęciach TestClass1, wpisz:

adb shell am instrument -w  \
> -e class com.android.demo.app.tests.TestClass1 \
> com.android.demo.app.tests/androidx.test.runner.AndroidJUnitRunner

Wybierz podzbiór testów

Aby uruchomić wszystkie testy w klasie TestClass1 i metodzie testMethod3 w TestClass2, wpisz:

adb shell am instrument -w \
> -e class com.android.demo.app.tests.TestClass1,com.android.demo.app.tests.TestClass2#testMethod3 \
> com.android.demo.app.tests/androidx.test.runner.AndroidJUnitRunner

Więcej przypadków użycia znajdziesz w dokumentacji API AndroidJUnitRunner.