Cómo orientar anuncios a un ejemplo de app

Esta categoría de prueba de instrumentación no es muy diferente de las de orientación las aplicaciones para Android normales. Cabe señalar que la aplicación de prueba que incluye la instrumentación, deben estar firmadas con el mismo certificado que la aplicación a la que se orienta.

Ten en cuenta que, en esta guía, se asume que ya tienes conocimientos sobre el del árbol de código fuente de la plataforma. De lo contrario, consulta los Requisitos. En el ejemplo que se aborda aquí, se escribe una nueva prueba de instrumentación con una configurado en su propio paquete de aplicación de prueba. Si desconoces el lee la Introducción a las pruebas de plataforma.

En esta guía, se usa la siguiente prueba para servir como muestra:

• frameworks/base/paquetes/Shell/pruebas

Se recomienda explorar el código primero para obtener una impresión aproximada antes de continuar.

Elige una ubicación de origen

Debido a que la prueba de instrumentación se orientará a una aplicación, la convención consiste en colocar el código fuente de prueba en un directorio tests debajo de la raíz de tu en el directorio del código fuente del componente en el árbol de fuentes de la plataforma.

Consulta más debates sobre la ubicación del origen en el ejemplo integral de pruebas de instrumentación autónoma.

Archivo de manifiesto

Al igual que una aplicación normal, cada módulo de prueba de instrumentación necesita un . Si nombras el archivo como AndroidManifest.xml y lo proporcionas a continuación en Android.mk para tu módulo de prueba, el módulo lo incluirá automáticamente Archivo makefile principal de BUILD_PACKAGE.

Antes de continuar, te recomendamos que consultes Descripción general del manifiesto de la app antes de empezar.

Aquí encontrarás una descripción general de los componentes básicos de un archivo de manifiesto y su funcionalidades.

Se puede acceder a la versión más reciente del archivo de manifiesto para el cambio de gerrit de muestra en: https://android.googlesource.com/platform/frameworks/base/+/main/packages/Shell/tests/AndroidManifest.xml

Aquí se incluye un resumen para tu comodidad:

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

Algunas observaciones seleccionadas sobre el archivo de manifiesto:

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

El atributo package es el nombre del paquete de la aplicación: es el único identificador que usa el framework de la aplicación para Android para identificar una tu aplicación de prueba (o, en este contexto, tu aplicación de prueba). Cada usuario del sistema solo puede instalar una aplicación con ese nombre de paquete.

Ya que este es un paquete de aplicación de prueba, independiente de la aplicación paquete bajo prueba, se debe usar un nombre de paquete diferente: una convención común es agregar un sufijo .test.

Además, este atributo package es igual a lo que ComponentName#getPackageName() y las que también usarías para interactuar con varias suscripciones de pm mediante adb shell.

Ten en cuenta también que, si bien el nombre del paquete suele tener el mismo estilo como nombre de paquete de Java, tiene muy pocas cosas que ver con él. En otro palabras, tu paquete de aplicación (o prueba) puede contener clases con cualquier paquete nombres, aunque por otro lado, podrías optar por la simplicidad y hacer que tus nombre de paquete de Java en tu aplicación o prueba idéntica a la de la aplicación el nombre del paquete.

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

Esto es obligatorio para todas las pruebas de instrumentación, ya que las clases relacionadas son empaquetado en un archivo de biblioteca jar del framework independiente, por lo que se requieren classpath cuando el framework de la aplicación invoca el paquete de prueba.

android:targetPackage="com.android.shell"

De esta manera, se establece el paquete de destino de la instrumentación en com.android.shell. Cuando se invoca la instrumentación a través del comando am instrument, el framework reinicia el proceso com.android.shell e inserta código de instrumentación en el proceso de ejecución de prueba. Esto también significa que el código de prueba tendrá acceso a todas las instancias de la clase que se ejecutan en la aplicación a prueba y puede y la capacidad de manipularlo depende de los hooks de prueba expuestos.

Archivo de configuración simple

Cada módulo de prueba nuevo debe tener un archivo de configuración para dirigir el sistema de compilación con metadatos de módulos, dependencias de tiempo de compilación y empaquetado instrucciones. En la mayoría de los casos, la opción de archivo de Blueprint basado en Soong es suficientes. Consulta Configuración de prueba simple para obtener más detalles.

Archivo de configuración complejo

Para pruebas más complejas, también debes escribir una configuración de prueba archivo del agente de prueba de Android, la Federación de Comercio.

La configuración de prueba puede especificar opciones especiales de configuración de dispositivos para proporcionar la clase de prueba.

Se puede acceder a la versión más reciente del archivo de configuración para el cambio de gerrit de muestra en: frameworks/base/packages/Shell/tests/AndroidTest.xml

Aquí se incluye un resumen para tu comodidad:

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

Algunas observaciones seleccionadas sobre el archivo de configuración de prueba:

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

Esto le indica a la Federación de Comercio que instale ShellTests.apk en el objetivo. usando un target_preparer especificado. Hay muchos preparadores de objetivos disponibles para los programadores de la Federación de Comercio y se pueden utilizar para garantizar que el dispositivo esté configurado correctamente antes de la ejecución de la prueba.

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

Especifica la clase de prueba de la Federación de Comercio que se usará para ejecutar la prueba y pase el paquete en el dispositivo que se ejecutará y el ejecutor de pruebas que, en este caso, es JUnit.

Obtén más información sobre la configuración de los módulos de prueba.

Funciones de JUnit4

El uso de la biblioteca android-support-test como ejecutor de pruebas permite la adopción de nuevos JUnit4, y el cambio de gerrit de muestra contiene algunas uso de sus funciones.

Se puede acceder al código fuente más reciente para el cambio de gerrit de muestra en: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java

Si bien los patrones de prueba suelen ser específicos de los equipos de componentes, hay algunos patrones de uso generalmente útiles.

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

Una diferencia significativa en JUnit4 es que las pruebas ya no son necesarias para heredarán de una clase de prueba base común; en su lugar, escribes pruebas en Java simple y usa anotaciones para indicar ciertas restricciones y configuraciones de prueba. En ejemplo, indicamos que esta clase debe ejecutarse como un SDK JUnit4.

La anotación @SmallTest especificó un tamaño de prueba para toda la clase de prueba: todos. Los métodos de prueba agregados a esta clase de prueba heredan esta anotación de tamaño de prueba. configuración previa de la clase de prueba, eliminación de la clase posterior a la prueba y eliminación de la clase posterior a la prueba: de manera similar a los métodos setUp y tearDown en JUnit4. La anotación Test se usa para anotar la prueba real.

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

La anotación @Before se usa en los métodos de JUnit4 para realizar la configuración de la prueba previa. Aunque no se usa en este ejemplo, también hay @After para la desmontaje posterior a la prueba. Del mismo modo, las anotaciones @BeforeClass y @AfterClass se pueden usar en métodos de JUnit4 para realizar la configuración antes de ejecutar todas las pruebas en una clase de prueba. y su posterior eliminación. Ten en cuenta que los métodos de configuración y desmontaje del alcance de clase deben ser estáticos.

En cuanto a los métodos de prueba, a diferencia de la versión anterior de JUnit, ya no necesitan para iniciar el nombre del método con test; en cambio, cada uno de ellos debe anotarse con @Test. Como siempre, los métodos de prueba deben ser públicos, no deben declarar ningún valor que se muestre no toman parámetros y pueden generar excepciones.

        Context context = InstrumentationRegistry.getTargetContext();

Debido a que las pruebas JUnit4 ya no requieren una clase base común, ya no es necesario para obtener instancias de Context a través de getContext() o getTargetContext() a través de métodos de clase base; en su lugar, el nuevo ejecutor de pruebas los administra a través de InstrumentationRegistry en la que la configuración contextual y del entorno creada por un framework de instrumentación se almacenan. En esta clase, también puedes llamar a los siguientes cursos:

• getInstrumentation(): Es la instancia para la clase Instrumentation.
• getArguments(): Los argumentos de la línea de comandos que se pasan a am instrument mediante -e <key> <value>

Compila y prueba de forma local

Para los casos de uso más comunes, emplea Atest (Atest).

Para casos más complejos que requieren una mayor personalización, sigue las instrucciones de instrumentación.