Najpierw przeczytaj Przetestuj swoją aplikację na developer.android.com. Zwróć uwagę, że istnieją pewne różnice w sposobie używania testów oprzyrządowania w testowaniu platformy.
Podsumowując, test oprzyrządowania zapewnia specjalne środowisko wykonywania testów uruchamiane za pomocą polecenia am instrument
, w którym docelowy proces aplikacji jest ponownie uruchamiany i inicjowany z podstawowym kontekstem aplikacji, a wątek oprzyrządowania jest uruchamiany w maszynie wirtualnej procesu aplikacji. Kod testowy rozpoczyna wykonywanie w tym wątku Instrumentacji i jest dostarczany z wystąpieniem Instrumentation
, które zapewnia dostęp do kontekstu aplikacji i interfejsów API w celu manipulowania testowanym procesem aplikacji.
Kluczowe idee
- Instrumentacja musi być zadeklarowana w pakiecie aplikacji z tagiem
<instrumentation>
zagnieżdżonym w tagu<manifest>
manifestu pakietu aplikacji. - manifest pakietu aplikacji może technicznie zawierać wiele
<instrumentation>
, chociaż nie jest to powszechnie używane w ten sposób. - każde
<instrumentation>
musi zawierać:- atrybut
android:name
: powinna to być nazwa podklasyInstrumentation
zawartej w aplikacji testowej, która zazwyczaj jest używanym programem uruchamiającym testy, np.:android.support.test.runner.AndroidJUnitRunner
- musi być zdefiniowany atrybut
android:targetPackage
. Jego wartość powinna być ustawiona na testowany pakiet aplikacji.
- atrybut
Podsumowanie kroków
Poniżej znajdują się typowe kierunki testów hermetycznych względem usług ramowych:
frameworks/base/core/tests/coretests frameworks/base/services/tests/servicestests
Jeśli dodajesz zupełnie nowy moduł oprzyrządowania dla swojego komponentu, zobacz
Postępuj zgodnie z istniejącą konwencją, jeśli dodajesz testy do jednej z powyższych lokalizacji. Jeśli konfigurujesz nowy moduł testowy, postępuj zgodnie z konfiguracją
AndroidManifest.xml
iAndroid.mk
w jednej z powyższych lokalizacjiZobacz frameworks/base/core/tests/coretests/ dla przykładu. Zwróć uwagę, że te wiersze instalują dodatkowe aplikacje:
<option name="test-file-name" value="FrameworksCoreTests.apk" /> <option name="test-file-name" value="BstatsTestApp.apk" />
Nie zapomnij oznaczyć swojego testu jako
@SmallTest
,@MediumTest
lub@LargeTest
Zbuduj moduł testowy za pomocą m, np.:
m FrameworksCoreTests
Uruchom testy:
Najprostszym rozwiązaniem jest użycie Atest w następujący sposób:
atest FrameworksCoreTests
Lub w przypadku bardziej złożonych testów użyj uprzęży testowej Federacji Handlowej :
m tradefed-all tradefed.sh run template/local_min --template:map test=FrameworksCoreTests
Jeśli nie korzystasz z Tradefed, ręcznie zainstaluj i uruchom testy:
- Zainstaluj wygenerowany apk:
adb install -r ${OUT}/data/app/FrameworksCoreTests/FrameworksCoreTests.apk
Uruchom testy z różnymi opcjami:
wszystkie testy w apk
adb shell am instrument -w com.android.frameworks.coretests\ /android.support.test.runner.AndroidJUnitRunner
wszystkie testy w ramach konkretnego pakietu Java
adb shell am instrument -w -e package android.animation \ com.android.frameworks.coretests\ /android.support.test.runner.AndroidJUnitRunner
wszystkie testy w ramach określonej klasy
adb shell am instrument -w -e class \ android.animation.AnimatorSetEventsTest \ com.android.frameworks.coretests\ /android.support.test.runner.AndroidJUnitRunner
specyficzna metoda badawcza
adb shell am instrument -w -e class \ android.animation.AnimatorSetEventsTest#testCancel \ com.android.frameworks.coretests\ /android.support.test.runner.AndroidJUnitRunner
Twój test może wykonać jawną asercję przy zaliczeniu lub niepowodzeniu przy użyciu interfejsów API JUnit
; ponadto wszelkie nieprzechwycone wyjątki spowodują również awarię funkcjonalną.
Aby wyemitować metryki wydajności, kod testowy może wywołać Instrumentation#sendStatus
w celu wysłania listy par klucz-wartość. Należy pamiętać, że:
- metryki mogą być liczbą całkowitą lub zmiennoprzecinkową
- wszelkie wartości nienumeryczne zostaną odrzucone
- Twój testowy apk może być albo testami funkcjonalnymi, albo testami metrykowymi, jednak mieszanie obu nie jest obecnie obsługiwane