Ta kategoria testów z instrumentacją nie różni się zbytnio od tych ustawień kierowania niż zwykłe aplikacje na Androida. Warto zauważyć, że aplikacja testowa który zawiera instrumentację, musi być podpisany tym samym certyfikatem jako docelowej aplikacji.
W tym przewodniku zakładamy, że masz już jakąś wiedzę w przepływie pracy drzewa źródłowego platformy. Jeśli tak nie jest, zapoznaj się z wymaganiami. Opisanym tu przykładem jest pisanie nowego testu narzędziowego z wartością docelową ustawionym jako własny pakiet aplikacji testowej. Jeśli nie znasz przeczytaj wprowadzenie do testowania platformy.
Ten przewodnik służy jako przykład do wykorzystania tego testu:
- platformy/bazy/pakiety/powłoki/testy
Zalecamy, aby najpierw przejrzeć kod, aby uzyskać ogólne informacje. zanim przejdziesz dalej.
Wybierz lokalizację źródłową
Ponieważ test instrumentacji będzie kierowany na aplikację, konwencja
umieszczenie testowego kodu źródłowego w katalogu tests
w katalogu głównym
katalog źródłowy komponentu w drzewie źródłowym platformy.
Więcej dyskusji na temat lokalizacji źródłowej znajdziesz w pełnym przykładzie dla samodzielnie instruujących testy.
Plik manifestu
Tak jak w przypadku zwykłej aplikacji, każdy moduł testowania narzędzi wymaga
manifestu. Jeśli nadasz plikowi nazwę AndroidManifest.xml
i podasz go w następnej kolejności
do Android.mk
dla testowego modułu tmodule, zostanie on automatycznie uwzględniony przez
BUILD_PACKAGE
główny plik Makefile.
Zanim przejdziesz dalej, zdecydowanie zalecamy zapoznanie się Omówienie pliku manifestu aplikacji .
Omówienie podstawowych komponentów pliku manifestu i ich funkcje.
Dostępna jest najnowsza wersja pliku manifestu przykładowej zmiany gerrit o: https://android.googlesource.com/platform/frameworks/base/+/main/packages/Shell/tests/AndroidManifest.xml
Dla wygody podajemy tu podsumowanie:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.shell.tests">
<application>
<uses-library android:name="android.test.runner" />
<activity
android:name="com.android.shell.ActionSendMultipleConsumerActivity"
android:label="ActionSendMultipleConsumer"
android:theme="@android:style/Theme.NoDisplay"
android:noHistory="true"
android:excludeFromRecents="true">
<intent-filter>
<action android:name="android.intent.action.SEND_MULTIPLE" />
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="*/*" />
</intent-filter>
</activity>
</application>
<instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
android:targetPackage="com.android.shell"
android:label="Tests for Shell" />
</manifest>
Kilka uwag na temat pliku manifestu:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.shell.tests">
Atrybut package
to nazwa pakietu aplikacji: jest to unikalna
identyfikator wykorzystywany przez platformę aplikacji na Androida do identyfikowania
aplikacji (lub w tym kontekście: aplikacji testowej). Każdy użytkownik w systemie
mogą zainstalować tylko jedną aplikację z tą nazwą pakietu.
Jest to pakiet aplikacji testowej niezależnej od aplikacji
testowany pakiet, należy użyć innej nazwy pakietu: jedna wspólna konwencja
jest dodanie sufiksu .test
.
Ponadto ten atrybut package
jest taki sam jak atrybut
ComponentName#getPackageName()
.
, a także tego samego, którego należy użyć do interakcji z różnymi podpunktami pm
za pomocą poleceń adb shell
.
Pamiętaj też, że chociaż nazwa pakietu jest zwykle taka sama jako nazwa pakietu Javy, tak naprawdę niewiele ma z nim wspólnego. W innym słowa, pakiet aplikacji (lub testowy) może zawierać klasy z dowolnym pakietem z kolei nazwy mogą być prostsze i wyjątkowe. nazwę pakietu Javy na poziomie w Twojej aplikacji lub testowa taka sama jak w aplikacji nazwę pakietu.
<uses-library android:name="android.test.runner" />
Jest to wymagane we wszystkich testach z instrumentacją, ponieważ powiązane klasy są w oddzielnym pliku biblioteki jar platformy, dlatego wymaga dodatkowych classpath, gdy pakiet testowy jest wywoływany przez platformę aplikacji.
android:targetPackage="com.android.shell"
Ustawia pakiet docelowy instrumentacji na com.android.shell
.
Gdy instrumentacja jest wywoływana za pomocą polecenia am instrument
, platforma
uruchamia ponownie proces com.android.shell
i wstrzykuje kod instrumentacji do
i przeprowadź proces wykonywania testu. Oznacza to również, że kod testowy będzie zawierać
dostępu do wszystkich instancji klas uruchomionych w testowanej aplikacji i może
możliwość manipulowania stanem zależy od ujawnionych punktów zaczepienia testu.
Prosty plik konfiguracji
Każdy nowy moduł testowy musi zawierać plik konfiguracji, który umożliwia system kompilacji z metadanymi modułów, zależnościami czasu kompilowania oraz sposobem prezentacji za instrukcje. W większości przypadków opcja pliku Blueprint oparta na oprogramowaniu Soong jest wystarczająca. Szczegółowe informacje znajdziesz w sekcji Prosta konfiguracja testu.
Złożony plik konfiguracji
W przypadku bardziej złożonych testów musisz też napisać konfigurację testową federacji handlu detalicznego.
Konfiguracja testu może określać specjalne opcje konfiguracji urządzenia i ustawienia domyślne. argumentów dostarczających klasę testową.
Dostępna jest najnowsza wersja pliku konfiguracyjnego przykładowej zmiany Gerrit o: frameworks/base/packages/Shell/tests/AndroidTest.xml
Dla wygody podajemy tu podsumowanie:
<configuration description="Runs Tests for Shell.">
<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
<option name="test-file-name" value="ShellTests.apk" />
</target_preparer>
<option name="test-suite-tag" value="apct" />
<option name="test-tag" value="ShellTests" />
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="com.android.shell.tests" />
<option name="runner" value="android.support.test.runner.AndroidJUnitRunner" />
</test>
</configuration>
Uwagi na temat testowego pliku konfiguracji:
<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
<option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>
Dzięki temu federacja handlowa powinna zainstalować plik ShellTests.apk w środowisku docelowym za pomocą określonego atrybutu target_preparer. Wiele osób przygotowujących do kierowania reklam dostępnych dla deweloperów w Federacji Handlowej. Można je wykorzystać, aby zagwarantować, sprawdź, czy urządzenie jest prawidłowo skonfigurowane przed rozpoczęciem testu.
<test class="com.android.tradefed.testtype.AndroidJUnitTest">
<option name="package" value="com.android.shell.tests"/>
<option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>
Określa klasę testową federacji handlowej, która ma zostać użyta do przeprowadzenia testu i przechodzi w pakiecie na urządzeniu, który ma zostać wykonany, a użytkownik wykonujący test czyli JUnit,
Tutaj znajdziesz więcej informacji o konfiguracjach modułu testowego
Funkcje JUnit4
Użycie biblioteki android-support-test
jako mechanizmu uruchamiania testów pozwala na zastosowanie nowych
klas testowych stylu JUnit4, a przykładowa zmiana gerrit zawiera pewne bardzo podstawowe
korzystanie z jego funkcji.
Najnowszy kod źródłowy przykładowej zmiany gerrit jest dostępny pod adresem: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java
Wzorce testowania są zwykle typowe dla zespołów składających się z poszczególnych zespołów, i przydatnych wzorców użytkowania.
@SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {
Znacząca różnica w JUnit4 polega na tym, że testy nie są już wymagane dziedziczenie ze wspólnej klasy podstawowej; zamiast tego piszesz w Javie. i używać adnotacji do wskazywania określonych konfiguracji i ograniczeń testów. W W tym przykładzie instruujemy, że ta klasa powinna być uruchamiana jako Test JUnit4.
Adnotacja @SmallTest
określa rozmiar testu dla całej klasy testowej: wszystkie
metody testowe dodane do tej klasy testowej dziedziczą tę adnotację dotyczącą rozmiaru testu.
przed rozpoczęciem lekcji, po zakończeniu testu i po zakończeniu zajęć:
podobne do metod setUp
i tearDown
w JUnit4.
Adnotacja Test
służy do oznaczania wyników testu.
@Before
public void setup() {
...
@Test
public void testGetProvider_shouldCacheProvider() {
...
Adnotacja @Before
jest używana w metodach JUnit4 do wstępnej konfiguracji testu.
Chociaż w tym przykładzie nie jest używany, istnieje również atrybut @After
do zakończenia działania testu po zakończeniu testu.
Adnotacje @BeforeClass
i @AfterClass
mogą też być używane w przypadku:
w JUnit4 w celu przeprowadzenia konfiguracji przed wykonaniem wszystkich testów w klasie testowej,
a później rozkładać. Pamiętaj, że metody konfiguracji i dezaktywacji zakresu klasy
musi być statyczny.
Jeśli chodzi o metody testowania, w przeciwieństwie do wcześniejszej wersji JUnit nie muszą one już
, aby nazwa metody zaczynała się od test
. Do każdej z nich należy dodać adnotacje
dzięki @Test
. Jak zwykle metody testów muszą być publiczne, zadeklarować brak wartości zwrotnej
nie przyjmuje żadnych parametrów i może generować wyjątki.
Context context = InstrumentationRegistry.getTargetContext();
Ponieważ testy JUnit4 nie wymagają już wspólnej klasy bazowej,
niezbędne do uzyskania instancji Context
za pomocą getContext()
lub
getTargetContext()
za pomocą metod klasy bazowej; Zamiast tego nowy biegacz
zarządza nimi w usłudze InstrumentationRegistry
gdzie konfiguracja kontekstowa i środowiskowa utworzona przez platformę instrumentacji
zapisane. W ramach tych zajęć możesz również zadzwonić:
getInstrumentation()
: wystąpienie do klasyInstrumentation
getArguments()
: argumenty wiersza poleceń przekazywane doam instrument
przez-e <key> <value>
Kompilowanie i testowanie lokalnie
W najczęstszych przypadkach użycia Atest.
W przypadku bardziej złożonych przypadków, które wymagają większych dostosowań, postępuj zgodnie z instrumentacji.