Google jest zaangażowany w promowanie równości rasowej dla społeczności czarnych. Zobacz jak.
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Kierowanie na przykład aplikacji

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

Zauważ, że ten przewodnik zakłada, że ​​masz już pewną wiedzę na temat przepływu pracy drzewa źródłowego platformy. Jeśli nie, zapoznaj się z https://source.android.com/source/requirements. Omawiany tutaj przykład to napisanie 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 .

Ten przewodnik używa następującego testu jako przykładu:

  • frameworki / baza / pakiety / powłoka / testy

Zaleca się najpierw przejrzeć kod, aby uzyskać ogólne wrażenie, zanim przejdziesz dalej.

Decydowanie o lokalizacji źródłowej

Ponieważ test oprzyrządowanie będzie kierowanie wniosku, konwencja jest umieszczenie kodu źródłowego badanie w tests katalogu poniżej katalogu głównego składnika katalogu źródłowego w drzewie źródłowym platforma.

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

Plik manifestu

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

Przed przystąpieniem do dalszych czynności zdecydowanie zalecamy najpierw przejrzenie przeglądu manifestu aplikacji .

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

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

Dla wygody dołączono migawkę:

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

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 unikatowy identyfikator, którego struktura aplikacji systemu Android używa do identyfikacji 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 pakiet aplikacji testowej, 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 ComponentName#getPackageName() , a także taki sam, jakiego można użyć do interakcji z różnymi poleceniami pm sub za pośrednictwem adb shell .

Należy również pamiętać, że chociaż nazwa pakietu jest zwykle w tym samym stylu, co nazwa pakietu Java, w rzeczywistości ma z nią niewiele wspólnego. Innymi słowy, Twój pakiet aplikacji (lub testowy) może zawierać klasy z dowolnymi nazwami pakietów, chociaż z drugiej strony możesz wybrać prostotę i mieć nazwę pakietu Java najwyższego poziomu w swojej aplikacji lub przetestować identyczną z nazwą pakietu aplikacji.

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

Jest to wymagane dla wszystkich testów Instrumentation, ponieważ powiązane klasy są spakowane w osobnym pliku biblioteki jar środowiska, dlatego wymaga dodatkowych wpisów ścieżki klas, gdy pakiet testowy jest wywoływany przez środowisko aplikacji.

 android:targetPackage="com.android.shell"
 

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

Prosty plik konfiguracyjny

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

Złożony plik konfiguracyjny

W przypadku bardziej złożonych testów musisz również napisać testowy plik konfiguracyjny dla wiązki testowej Androida, Trade Federation .

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

Dla wygody dołączono migawkę:

 <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 uwagi dotyczące testowego pliku konfiguracyjnego:

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

Informuje to Trade Federation o zainstalowaniu ShellTests.apk na urządzeniu docelowym przy użyciu określonego target_preparer. Istnieje wiele programów przygotowujących dane docelowe dostępnych dla programistów w Trade Federation i można ich użyć, aby upewnić się, że urządzenie jest prawidłowo skonfigurowane 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ą Trade Federation, która ma być używana do wykonania testu, i przekazuje pakiet na urządzeniu, które ma zostać wykonane, oraz platformę uruchamiającą testy, którą w tym przypadku jest JUnit.

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

Funkcje JUnit4

Użycie biblioteki android-support-test jako narzędzia do uruchamiania testów umożliwia przyjęcie nowych klas testowych w stylu JUnit4, a przykładowa zmiana gerrit zawiera bardzo podstawowe zastosowania jej 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

Chociaż 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 {
 

Istotna różnica w JUnit4 polega na tym, że testy nie muszą już dziedziczyć ze wspólnej podstawowej klasy testów; zamiast tego piszesz testy w zwykłych klasach Java i używasz adnotacji, aby wskazać określone ustawienia testu i ograniczenia. W tym przykładzie instruujemy, że ta klasa powinna zostać uruchomiona jako test Android JUnit4.

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

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

Adnotacja @Before jest używana w metodach JUnit4 w celu wykonania konfiguracji przed testem. Chociaż nie jest używany w tym przykładzie, istnieje również @After do @After po teście. Podobnie adnotacje @BeforeClass i @AfterClass mogą być używane w metodach JUnit4 w celu wykonania konfiguracji przed wykonaniem wszystkich testów w klasie testowej, a następnie po ich usunięciu. Zwróć uwagę, że metody konfiguracji zakresu klasy i dezaktywacji muszą być statyczne.

Jeśli chodzi o metody testowe, w przeciwieństwie do wcześniejszej wersji JUnit, nie muszą już rozpoczynać 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ć parametrów i mogą generować 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ą metody getContext() lub getTargetContext() za pośrednictwem metod klasy bazowej; zamiast tego nowy program uruchamiający testy zarządza nimi za pośrednictwem InstrumentationRegistry którym przechowywane są ustawienia kontekstowe i środowiskowe utworzone przez platformę Instrumentation. Za pośrednictwem tej klasy możesz również zadzwonić:

  • getInstrumentation() : instancja klasy Instrumentation
  • getArguments() : argumenty wiersza poleceń przekazane do am instrument za pomocą -e <key> <value>

Twórz i testuj lokalnie

W najczęstszych przypadkach użyj Atest .

W przypadku bardziej złożonych przypadków wymagających bardziej szczegółowego dostosowania postępuj zgodnie z instrukcjami oprzyrządowania .