Ориентация на пример приложения

Эта категория инструментальных тестов не сильно отличается от тех, которые предназначены для обычных приложений Android. Стоит отметить, что тестовое приложение, включающее инструментарий, должно быть подписано тем же сертификатом, что и приложение, на которое оно нацелено.

Обратите внимание, что в этом руководстве предполагается, что у вас уже есть некоторые знания о рабочем процессе дерева исходного кода платформы. Если нет, обратитесь к https://source.android.com/source/requirements. Рассмотренный здесь пример - написание нового инструментального теста с целевым пакетом, установленным в собственном пакете тестового приложения. Если вы не знакомы с концепцией, пожалуйста , ознакомьтесь с тестированием внедрения платформы .

В этом руководстве в качестве образца используется следующий тест:

  • фреймворки / база / пакеты / оболочка / тесты

Прежде чем продолжить, рекомендуется сначала просмотреть код, чтобы получить общее представление.

Выбор местоположения источника

Поскольку контрольные приборы будут предназначаться приложением, соглашение является размещение исходного кода теста в tests каталоге в корневом каталоге вашего компонента исходного каталога в исходном дереве платформы.

Другие дискуссии о месте расположения источника в примере впритык для самостоятельной инструментирование испытаний .

Файл манифеста

Как и в случае с обычным приложением, каждому модулю инструментального тестирования требуется файл манифеста. Если имя файла как AndroidManifest.xml и обеспечить его рядом с Android.mk для тестовой TModule, он будет получать автоматически включаются в BUILD_PACKAGE основной Makefile.

Прежде чем продолжить, настоятельно рекомендуется пройти через App Manifest Обзор первого.

Это дает обзор основных компонентов файла манифеста и их функций.

Последнюю версию файла манифеста для образца изменения gerrit можно найти по адресу: https://android.googlesource.com/platform/frameworks/base/+/master/packages/Shell/tests/AndroidManifest.xml.

Сюда для удобства включен снимок:

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

Некоторые избранные примечания к файлу манифеста:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

package атрибут имя пакета приложения: это уникальный идентификатор , что Android рамочные приложения использует для идентификации приложения (или в этом контексте: ваше тестовое приложение). Каждый пользователь в системе может установить только одно приложение с этим именем пакета.

Поскольку это пакет прикладных программ испытаний, независимо от пакета прикладных программ при испытании, необходимо использовать другое имя пакета: одна общая конвенция добавить суффикс .test .

Кроме того, этот package атрибут такого же , как то , что ComponentName#getPackageName() возвращает, а также то же самое вы бы использовать для взаимодействия с различными pm команд подразделов через adb shell .

Также обратите внимание, что хотя имя пакета обычно имеет тот же стиль, что и имя пакета Java, на самом деле оно имеет очень мало общего. Другими словами, ваш пакет приложения (или теста) может содержать классы с любыми именами пакетов, хотя, с другой стороны, вы можете выбрать простоту и иметь имя пакета Java верхнего уровня в вашем приложении или тесте, идентичном имени пакета приложения.

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

Это требуется для всех инструментальных тестов, поскольку связанные классы упакованы в отдельный файл библиотеки jar фреймворка, поэтому требуются дополнительные записи пути к классам, когда тестовый пакет вызывается фреймворком приложения.

android:targetPackage="com.android.shell"

Это устанавливает целевой пакет приборов для com.android.shell . Когда аппаратура вызывается с помощью am instrument команды, каркасные перезагружается com.android.shell процесс, и впрыскивает приборостроение код в процессе выполнения теста. Это также означает, что тестовый код будет иметь доступ ко всем экземплярам класса, запущенным в тестируемом приложении, и сможет управлять состоянием в зависимости от выставленных тестовых перехватчиков.

Простой файл конфигурации

Каждый новый тестовый модуль должен иметь файл конфигурации, чтобы направлять систему сборки с метаданными модуля, зависимостями времени компиляции и инструкциями по упаковке. В большинстве случаев достаточно использовать файл Blueprint на основе Soong. См Простая конфигурация испытаний для деталей.

Сложный файл конфигурации

Для более сложных испытаний, также необходимо написать файл конфигурации тестирования для тестового жгуте Андроида, Торговой Федерации .

Конфигурация теста может указывать специальные параметры настройки устройства и аргументы по умолчанию для предоставления тестового класса.

Последняя версия конфигурационного файла для образца изменения Геррит можно получить по адресу: каркасы / базовые / пакеты / Shell / тесты / AndroidTest.xml

Сюда для удобства включен снимок:

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

Некоторые избранные примечания к файлу конфигурации теста:

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

Это указывает Trade Federation установить ShellTests.apk на целевое устройство, используя указанный target_preparer. Разработчикам в Торговой федерации доступно множество средств подготовки целевых приложений, которые можно использовать для обеспечения правильной настройки устройства перед выполнением теста.

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

Он определяет тестовый класс Trade Federation, который будет использоваться для выполнения теста, и передает пакет на устройство, которое будет выполнено, и среду выполнения тестов, которой в данном случае является JUnit.

Посмотрите здесь для получения дополнительной информации о модуле Test конфиги

Возможности JUnit4

Использование android-support-test библиотеку в качестве тест - бегуна позволяет сбор на новых тестовых классов JUnit4 стиля и образец изменения Геррит содержит некоторые основные использование его возможностей.

Последний исходный код для образца изменения Геррит можно получить по адресу: каркасы / базы / пакеты / Shell / тесты / SRC / COM / андроид / оболочка / BugreportReceiverTest.java

Хотя шаблоны тестирования обычно специфичны для команд компонентов, есть несколько общепринятых шаблонов использования.

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

Существенное отличие JUnit4 состоит в том, что тесты больше не требуют наследования от общего базового тестового класса; вместо этого вы пишете тесты в простых Java-классах и используете аннотации для обозначения определенных настроек и ограничений теста. В этом примере мы указываем, что этот класс должен запускаться как тест Android JUnit4.

@SmallTest аннотация указан размером теста для всего класса теста: все методы испытаний , добавленные в этот тестовом класс наследует эту тестового размер аннотацию. предварительно испытательная установка класса, после теста на разрыв вниз, и после тестового класса слезы вниз: по аналогии с setUp и tearDown методов в JUnit4. Test аннотации используются для аннотирования фактического испытания.

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

@Before аннотации используются на методы по JUnit4 выполнить предварительную испытательную установку. Хотя не используется в этом примере, есть также @After для поста теста демонтажа. Подобным же образом , @BeforeClass и @AfterClass аннотации могут быть использованы методы по JUnit4 для выполнения настройки перед выполнением всех тестов в тестовом классе, и после демонтажа. Обратите внимание, что методы установки и удаления в области класса должны быть статическими.

Что касается методов испытаний, в отличие от более ранней версии JUnit, они больше не нужно начинать имя методы с test , вместо этого, каждый из них должен быть аннотированный с @Test . Как обычно, методы тестирования должны быть общедоступными, не объявлять возвращаемое значение, не принимать параметров и вызывать исключения.

        Context context = InstrumentationRegistry.getTargetContext();

Поскольку JUnit4 тестов больше не требуется общий базовый класс, это больше не нужно , чтобы получить Context экземпляры через getContext() или getTargetContext() с помощью методов базового класса; вместо этого, новый тест бегун управляет ими через InstrumentationRegistry где контекстная и экологические установки созданы основы приборного хранится. Через этот класс вы также можете вызвать:

  • getInstrumentation() : экземпляр к Instrumentation класса
  • getArguments() : аргументы командной строки , передаваемые am instrument через -e <key> <value>

Сборка и тестирование локально

В большинстве случаев общего пользования, нанимают Atest .

Для более сложных случаев , требующих более тяжелые настройки, следуйте инструкциям КИП .