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 pamiętać, że testowa aplikacja zawierająca instrumentację musi być podpisana tym samym certyfikatem co aplikacja, na którą jest kierowana.

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 tego zagadnienia, 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 informacji o lokalizacji źródła znajdziesz w pełnym przykładzie testów samoinstruowania.

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 prześlesz go do Android.mk w przypadku testowego modułu, zostanie on automatycznie uwzględniony w pliku makefile BUILD_PACKAGE.

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.

Co więcej, atrybut package jest taki sam jak zwracany przez ComponentName#getPackageName(), a także taki sam, którego używasz do interakcji z różnymi podrzędnymi poleceniami pm za pomocą adb shell.

Pamiętaj też, że chociaż nazwa pakietu jest zwykle w tym samym stylu co nazwa pakietu Java, w istocie ma z nią niewiele wspólnego. Innymi słowy, pakiet aplikacji (lub testu) może zawierać klasy o dowolnych nazwach pakietów, ale z drugiej strony możesz postawić na prostotę i użyć w aplikacji lub teście nazwy pakietu Java na najwyższym poziomie identycznej z nazwą pakietu aplikacji.

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

Więcej informacji o konfiguracjach testowych modułów

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 tym przykładzie wskazujemy, że ta klasa powinna być uruchamiana jako test JUnit4 na Androida.

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ą być też 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 wymagają 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 także 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.