Orientación a un ejemplo de aplicación

Esta categoría de prueba de instrumentación no es tan diferente de las que se dirigen a las aplicaciones regulares de Android. Vale la pena señalar que la aplicación de prueba que incluía la instrumentación debe estar firmada con el mismo certificado que la aplicación a la que se dirige.

Tenga en cuenta que esta guía asume que ya tiene algún conocimiento en el flujo de trabajo del árbol de fuentes de la plataforma. De lo contrario, consulte https://source.android.com/source/requirements. El ejemplo cubierto aquí es escribir una nueva prueba de instrumentación con el paquete de destino establecido en su propio paquete de aplicación de prueba. Si no está familiarizado con el concepto, lea la Introducción a las pruebas de la plataforma .

Esta guía utiliza la siguiente prueba como muestra:

• frameworks/base/paquetes/Shell/pruebas

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

Decidir sobre una ubicación de origen

Debido a que la prueba de instrumentación tendrá como objetivo una aplicación, la convención es colocar el código fuente de la prueba en un directorio de tests debajo de la raíz del directorio fuente de su componente en el árbol fuente de la plataforma.

Vea más discusiones sobre la ubicación de la fuente en el ejemplo de extremo a extremo para las pruebas de autoinstrumentación .

archivo de manifiesto

Al igual que una aplicación normal, cada módulo de prueba de instrumentación necesita un archivo de manifiesto. Si nombra el archivo como AndroidManifest.xml y lo proporciona junto a Android.mk para su tmodule de prueba, se incluirá automáticamente en el archivo MAKE central BUILD_PACKAGE .

Antes de continuar, se recomienda encarecidamente revisar primero la descripción general del manifiesto de la aplicación .

Esto brinda una descripción general de los componentes básicos de un archivo de manifiesto y sus funcionalidades.

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

Se incluye una instantánea aquí para mayor 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>

Algunos comentarios selectos sobre el archivo de manifiesto:

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

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

Dado que este es un paquete de aplicación de prueba, independiente del paquete de aplicación 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 el mismo que ComponentName#getPackageName() , y también el mismo que usaría para interactuar con varios subcomandos pm a través adb shell .

Tenga en cuenta también que, aunque el nombre del paquete suele tener el mismo estilo que el nombre de un paquete de Java, en realidad tiene muy pocas cosas que ver con él. En otras palabras, su paquete de aplicación (o prueba) puede contener clases con cualquier nombre de paquete, aunque, por otro lado, puede optar por la simplicidad y tener el nombre de su paquete Java de nivel superior en su aplicación o prueba idéntico al nombre del paquete de la aplicación.

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

Esto es necesario para todas las pruebas de instrumentación, ya que las clases relacionadas se empaquetan en un archivo de biblioteca jar del marco de trabajo independiente, por lo que requiere entradas adicionales de ruta de acceso de clases cuando el marco de la aplicación invoca el paquete de prueba.

android:targetPackage="com.android.shell"

Esto 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 marco reinicia el proceso com.android.shell e inyecta el código de instrumentación en el proceso para la ejecución de la prueba. Esto también significa que el código de prueba tendrá acceso a todas las instancias de clase que se ejecutan en la aplicación bajo prueba y puede manipular el estado dependiendo de los ganchos de prueba expuestos.

Archivo de configuración sencillo

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

Archivo de configuración complejo

Importante: Las instrucciones de esta sección son necesarias solo para las pruebas CTS o aquellas que requieren una configuración especial, como desactivar Bluetooth o recopilar datos de muestra. Todos los demás casos se pueden cubrir a través de la configuración de prueba simple . Consulte Configuración de prueba compleja para obtener más detalles aplicables a esta sección.

Para pruebas más complejas, también debe escribir un archivo de configuración de prueba para el arnés de prueba de Android, Trade Federation .

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

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

Se incluye una instantánea aquí para mayor 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>

Algunos comentarios selectos 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 dice a Trade Federation que instale ShellTests.apk en el dispositivo de destino utilizando un target_preparer especificado. Hay muchos preparadores de objetivos disponibles para los desarrolladores en Trade Federation y estos se pueden usar 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>

Esto especifica la clase de prueba de Trade Federation que se usará para ejecutar la prueba y pasa el paquete en el dispositivo que se ejecutará y el marco del corredor de prueba, que es JUnit en este caso.

Mire aquí para obtener más información sobre las configuraciones del módulo de prueba

Características de JUnit4

El uso de la biblioteca de android-support-test como corredor de prueba permite la adopción de nuevas clases de prueba de estilo JUnit4, y el cambio de gerrit de muestra contiene un uso muy básico de sus características.

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, existen algunos patrones de uso generalmente útiles.

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

Una diferencia significativa en JUnit4 es que ya no es necesario que las pruebas hereden de una clase de prueba base común; en su lugar, escribe pruebas en clases simples de Java y usa anotaciones para indicar ciertas configuraciones y restricciones de prueba. En este ejemplo, indicamos que esta clase debe ejecutarse como una prueba de Android 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 de clase previa a la prueba, desmontaje posterior a la prueba y desmontaje de clase posterior a la prueba: similar a los métodos de configuración y tearDown en setUp . La anotación Test se utiliza para anotar la prueba real.

Importante: los métodos de prueba en sí están anotados con la anotación @Test ; y tenga en cuenta que para que las pruebas se ejecuten a través de APCT, deben anotarse con tamaños de prueba. Dicha anotación se puede aplicar en el ámbito del método o en el ámbito de la clase.

    @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 previa a la prueba. Aunque no se usa en este ejemplo, también hay @After para el desmontaje posterior a la prueba. De manera similar, 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 desmantelarlas después. Tenga en cuenta que los métodos de configuración y eliminación del ámbito 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 comenzar el nombre del método con test , sino que cada uno de ellos debe anotarse con @Test . Como de costumbre, los métodos de prueba deben ser públicos, no declarar valor de retorno, no tomar 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 obtener instancias de Context a través getContext() o getTargetContext() a través de métodos de clase base; en cambio, el nuevo ejecutor de pruebas los administra a través de InstrumentationRegistry , donde se almacena la configuración contextual y ambiental creada por el marco de instrumentación. A través de esta clase, también puede llamar a:

• getInstrumentation() : la instancia de la clase de Instrumentation
• getArguments() : los argumentos de la línea de comando pasados ​​a un am instrument a través de -e <key> <value>

Cree y pruebe localmente

Para los casos de uso más comunes, emplee Atest .

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