Przykładowa aplikacja do kierowania

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 klasy Instrumentation
  • getArguments(): argumenty wiersza poleceń przekazywane do am 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.