Google стремится продвигать расовую справедливость для черных сообществ. Смотри как.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

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

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

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

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

  • каркасы / базы / пакеты / Shell / тесты

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

Выбор исходного местоположения

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

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

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

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

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

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

С последней версией файла манифеста для примера изменения геррита можно ознакомиться по адресу: 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() , и также тот же, который вы использовали бы для взаимодействия с различными ComponentName#getPackageName() pm через adb shell .

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

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

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

 android:targetPackage="com.android.shell"
 

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

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

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

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

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

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

Последняя версия файла конфигурации для примера изменения gerrit доступна по адресу: frameworks / base / packages / Shell / tests / 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.

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

Особенности JUnit4

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

Последний исходный код для примера изменения Gerrit можно получить по адресу: frameworks / base / packages / Shell / tests / src / com / android / shell / BugreportReceiverTest.java

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

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

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

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

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

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

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

         Context context = InstrumentationRegistry.getTargetContext();
 

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

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

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

Для наиболее распространенных случаев использования используйте Atest .

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