Przykład kierowania aplikacji

Ta kategoria testów oprzyrządowania nie różni się zbytnio od testów ukierunkowanych na zwykłe aplikacje na Androida. Warto zauważyć, że aplikacja testowa, która zawiera instrumentację, musi być podpisana tym samym certyfikatem, co aplikacja, dla której jest przeznaczona.

Należy pamiętać, że w tym przewodniku założono, że masz już pewną wiedzę na temat przepływu pracy drzewa źródeł platformy. Jeśli nie, zapoznaj się z wymaganiami . Omówiony tutaj przykład polega na napisaniu nowego testu oprzyrządowania z pakietem docelowym ustawionym we własnym pakiecie aplikacji testowej. Jeśli nie znasz tej koncepcji, przeczytaj wprowadzenie do testowania platformy .

W tym przewodniku wykorzystano następujący test jako przykład:

• Frameworks/base/packages/Shell/tests

Zaleca się, aby najpierw przejrzeć kod, aby uzyskać ogólne wrażenie przed kontynuowaniem.

Decydowanie o lokalizacji źródła

Ponieważ test oprzyrządowania będzie ukierunkowany na aplikację, konwencja polega na umieszczeniu kodu źródłowego testu w katalogu tests w katalogu głównym katalogu źródłowego składnika w drzewie źródeł platformy.

Zobacz więcej dyskusji na temat lokalizacji źródła w kompleksowym przykładzie testów samoprzyrządowania .

Plik manifestu

Podobnie jak w przypadku zwykłej aplikacji, każdy moduł testowy oprzyrządowania wymaga pliku manifestu. Jeśli nazwiesz plik jako AndroidManifest.xml i podasz go obok Android.mk dla swojego testowego tmodułu, zostanie on automatycznie dołączony przez główny makefile BUILD_PACKAGE .

Zanim przejdziesz dalej, zdecydowanie zalecamy przejrzenie omówienia manifestu aplikacji .

Daje to przegląd podstawowych składników pliku manifestu i ich funkcjonalności.

Najnowsza wersja pliku manifestu dla przykładowej zmiany gerrit jest dostępna pod adresem: https://android.googlesource.com/platform/frameworks/base/+/main/packages/Shell/tests/AndroidManifest.xml

Migawka jest tutaj dla wygody:

<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>

Niektóre wybrane uwagi dotyczące 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 unikalny identyfikator używany przez platformę aplikacji Android do identyfikowania aplikacji (lub w tym kontekście: aplikacji testowej). Każdy użytkownik w systemie może zainstalować tylko jedną aplikację o tej nazwie pakietu.

Ponieważ jest to testowy pakiet aplikacji, niezależny od testowanego pakietu aplikacji, należy użyć innej nazwy pakietu: jedną z powszechnych konwencji jest dodanie sufiksu .test .

Co więcej, ten atrybut package jest taki sam, jak ten, który zwraca ComponentName#getPackageName() , a także ten sam, którego użyłbyś do interakcji z różnymi podkomendami pm przez adb shell .

Należy również zauważyć, że chociaż nazwa pakietu jest zazwyczaj w tym samym stylu, co nazwa pakietu Java, w rzeczywistości ma z nią bardzo niewiele wspólnego. Innymi słowy, twój pakiet aplikacji (lub testu) może zawierać klasy o dowolnych nazwach pakietów, chociaż z drugiej strony możesz zdecydować się na prostotę i mieć nazwę pakietu Java najwyższego poziomu w swojej aplikacji lub teście identyczną z nazwą pakietu aplikacji.

<uses-library android:name="android.test.runner" />

Jest to wymagane w przypadku wszystkich testów oprzyrządowania, ponieważ powiązane klasy są spakowane w osobnym pliku biblioteki jar platformy, dlatego wymagane są dodatkowe wpisy ścieżki klasy, gdy pakiet testowy jest wywoływany przez platformę aplikacji.

android:targetPackage="com.android.shell"

Spowoduje to ustawienie pakietu docelowego instrumentacji na com.android.shell . Gdy instrumentacja jest wywoływana za pomocą polecenia am instrument , struktura ponownie uruchamia proces com.android.shell i wstrzykuje kod instrumentacji do procesu w celu wykonania testu. Oznacza to również, że kod testowy będzie miał dostęp do wszystkich instancji klas działających w testowanej aplikacji i może manipulować stanem w zależności od ujawnionych haków testowych.

Prosty plik konfiguracyjny

Każdy nowy moduł testowy musi mieć plik konfiguracyjny do kierowania systemem kompilacji z metadanymi modułu, zależnościami w czasie kompilacji i instrukcjami dotyczącymi pakowania. W większości przypadków opcja pliku Blueprint oparta na Soong jest wystarczająca. Aby uzyskać szczegółowe informacje, zobacz Prosta konfiguracja testu .

Złożony plik konfiguracyjny

Ważne: Instrukcje zawarte w tej sekcji są potrzebne tylko w przypadku testów CTS lub tych, które wymagają specjalnej konfiguracji, takiej jak wyłączenie Bluetooth lub zbieranie przykładowych danych. Wszystkie inne przypadki można objąć za pomocą prostej konfiguracji testu . Zobacz złożoną konfigurację testu , aby uzyskać więcej informacji dotyczących tej sekcji.

W przypadku bardziej złożonych testów należy również napisać plik konfiguracji testu dla wiązki testowej Androida, Trade Federation .

Konfiguracja testu może określać specjalne opcje konfiguracji urządzenia i domyślne argumenty w celu dostarczenia klasy testowej.

Najnowsza wersja pliku konfiguracyjnego dla przykładowej zmiany gerrit jest dostępna pod adresem: frameworks/base/packages/Shell/tests/AndroidTest.xml

Migawka jest tutaj dla wygody:

<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>

Niektóre wybrane uwagi dotyczące pliku konfiguracyjnego testu:

<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
  <option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>

To mówi Federacji Handlowej, aby zainstalowała ShellTests.apk na urządzeniu docelowym przy użyciu określonego target_preparer. Deweloperzy w Federacji Handlowej mają do dyspozycji wiele narzędzi do przygotowywania obiektów docelowych, które można wykorzystać do zapewnienia prawidłowej konfiguracji urządzenia przed wykonaniem 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 wykonania testu i przechodzi w pakiecie na urządzeniu, które ma zostać wykonane, oraz środowisko do uruchamiania testów, którym w tym przypadku jest JUnit.

Zajrzyj tutaj, aby uzyskać więcej informacji na temat konfiguracji modułu testowego

Funkcje JUnit4

Używanie biblioteki android-support-test jako programu uruchamiającego testy umożliwia przyjęcie nowych klas testowych w stylu JUnit4, a przykładowa zmiana gerrit zawiera bardzo podstawowe wykorzystanie jej funkcji.

Dostęp do najnowszego kodu źródłowego przykładowej zmiany gerrit można znaleźć pod adresem: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java

Podczas gdy wzorce testowania są zwykle specyficzne dla zespołów składowych, istnieje kilka ogólnie użytecznych wzorców użycia.

@SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {

Istotną różnicą w JUnit4 jest to, że testy nie muszą już dziedziczyć ze wspólnej podstawowej klasy testowej; zamiast tego piszesz testy w zwykłych klasach Java i używasz adnotacji do wskazania określonej konfiguracji testu i ograniczeń. W tym przykładzie instruujemy, że ta klasa powinna być uruchamiana jako test Android JUnit4.

Adnotacja @SmallTest określa rozmiar testu dla całej klasy testowej: wszystkie metody testowe dodane do tej klasy testowej dziedziczą tę adnotację rozmiaru testu. konfiguracja klasy przed testem, zerwanie po teście i zerwanie klasy po teście: podobnie do metod setUp i tearDown w JUnit4. Adnotacja Test służy do opisywania rzeczywistego testu.

Ważne: same metody testowe są opatrzone adnotacją @Test ; i zwróć uwagę, że aby testy mogły być wykonywane przez APCT, muszą być opatrzone adnotacjami o rozmiarach testów. Taka adnotacja może być zastosowana w zakresie metody lub w zakresie klasy.

    @Before
    public void setup() {
    ...
    @Test
    public void testGetProvider_shouldCacheProvider() {
    ...

Adnotacja @Before jest używana w metodach JUnit4 do przeprowadzania konfiguracji przed testem. Chociaż nie jest używany w tym przykładzie, istnieje również @After do rozerwania po teście. Podobnie, adnotacje @BeforeClass i @AfterClass mogą być używane w metodach JUnit4 do przeprowadzania konfiguracji przed wykonaniem wszystkich testów w klasie testowej, a następnie rozbierania. Należy zauważyć, że metody konfigurowania i niszczenia zakresu klas muszą być statyczne.

Jeśli chodzi o metody testowe, w przeciwieństwie do wcześniejszych wersji JUnit, nie muszą już zaczynać nazwy metody od test , zamiast tego każda z nich musi być opatrzona adnotacją @Test . Jak zwykle, metody testowe muszą być publiczne, nie deklarować wartości zwracanej, nie przyjmować żadnych parametrów i mogą zgłaszać wyjątki.

        Context context = InstrumentationRegistry.getTargetContext();

Ponieważ testy JUnit4 nie wymagają już wspólnej klasy bazowej, nie jest już konieczne uzyskiwanie instancji Context za pomocą getContext() lub getTargetContext() za pomocą metod klasy podstawowej; zamiast tego nowy program uruchamiający testy zarządza nimi za pośrednictwem InstrumentationRegistry , w którym przechowywane są ustawienia kontekstowe i środowiskowe utworzone przez platformę oprzyrządowania. Za pośrednictwem tej klasy możesz również zadzwonić:

• getInstrumentation() : instancja klasy Instrumentation
• getArguments() : argumenty wiersza poleceń przekazywane do am instrument przez -e <key> <value>

Twórz i testuj lokalnie

W przypadku najczęstszych przypadków użycia zastosuj Atest .

W przypadku bardziej złożonych przypadków wymagających większego dostosowania postępuj zgodnie z instrukcjami dotyczącymi oprzyrządowania .