Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

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 algunos conocimientos sobre 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 configurado en su propio paquete de aplicación de prueba. Si no está familiarizado con el concepto, por favor, lea a través de la introducción Plataforma de la prueba .

Esta guía utiliza la siguiente prueba como muestra:

  • frameworks / base / paquetes / Shell / tests

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

Decidir la ubicación de origen

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

Ver más discusiones sobre la ubicación de origen en el ejemplo de extremo a extremo para las pruebas de auto-instrumentació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 la proporcione junto a Android.mk para su Tmodule prueba, que conseguirá automáticamente incluido por el BUILD_PACKAGE makefile núcleo.

Antes de seguir adelante, es muy recomendable que pasar por la App Manifiesto general primero.

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

Aquí se incluye una instantánea 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>

Algunas observaciones selectas sobre el archivo de manifiesto:

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

El package atributo es el nombre del paquete de aplicaciones: este es el identificador único que utiliza el marco de la aplicación Android para identificar una aplicación (o en este contexto: la 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 aplicaciones de prueba, independiente del paquete de la aplicación que se está probando, otro nombre de paquete debe ser utilizado: una convención común es añadir un sufijo .test .

Además, este package atributo es el mismo que lo ComponentName#getPackageName() regresa, y también el mismo que se utiliza para interactuar con diversos pm comandos sub través de adb shell .

Tenga en cuenta también que, aunque el nombre del paquete suele tener el mismo estilo que el nombre del paquete 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 están empaquetadas en un archivo de biblioteca jar de marco separado, por lo que requiere entradas de ruta de clase adicionales cuando el marco de aplicación invoca el paquete de prueba.

android:targetPackage="com.android.shell"

Esto fija el paquete de destino de la instrumentación a com.android.shell . Cuando la instrumentación es llamada a través am instrument de comandos, se reinicia el marco com.android.shell proceso, y el código de instrumentación inyecta en el proceso de 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 podrá manipular el estado dependiendo de los ganchos de prueba expuestos.

Archivo de configuración simple

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 basado en Soong es suficiente. Ver test sencillo para más detalles.

Archivo de configuración complejo

Para las pruebas más complejas, también es necesario para escribir un archivo de configuración de prueba para la herramienta de prueba de Android, la Federación de Comercio .

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

La última versión del archivo de configuración para el cambio Gerrit muestra se puede visitar en: marcos / base / packages / Shell / pruebas / AndroidTest.xml

Aquí se incluye una instantánea 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>

Algunas observaciones selectas 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 usando un target_preparer especificado. Hay muchos preparadores de objetivos disponibles para los desarrolladores en Trade Federation y estos 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>

Esto especifica la clase de prueba de la Federación de Comercio que se usará para ejecutar la prueba y pasa el paquete en el dispositivo que se ejecutará y el marco de ejecución de la prueba, que es JUnit en este caso.

Mira aquí para obtener más información sobre el módulo de prueba Configs

Funciones de JUnit4

El uso android-support-test biblioteca como corredor de prueba permite la adoptación de nuevas clases de prueba de estilo junit4, y el cambio Gerrit muestra contiene algún uso muy básico de sus características.

Último código fuente para el cambio gerrit muestra se puede acceder en: marcos / base / paquetes / cáscara / pruebas / src / com / android / cáscara / 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 se requiere 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 restricciones y configuraciones de prueba. En este ejemplo, estamos indicando que esta clase debe ejecutarse como una prueba de Android JUnit4.

El @SmallTest anotación especifica un tamaño de la prueba para toda la clase de prueba: todos los métodos de prueba agregados en esta clase de prueba heredan esta anotación tamaño de la prueba. pre configuración de prueba de clase, prueba de lágrima por correo, por el uso de clases después de la prueba hacia abajo: similar a setUp y tearDown métodos en junit4. Test de anotación se utiliza para describir la prueba real.

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

El @Before anotación se utiliza en los métodos de junit4 para llevar a cabo la configuración de prueba previa. Aunque no se utiliza en este ejemplo, también hay @After de desmontaje posterior a la prueba. Del mismo modo, los @BeforeClass y @AfterClass anotaciones se pueden utilizar en los métodos de junit4 a realizar la configuración antes de ejecutar todas las pruebas en una clase de prueba, y el desmontaje después. Tenga en cuenta que los métodos de instalación y desmontaje 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, que ya no necesitan para iniciar el nombre del método de test , en cambio, cada uno de ellos debe ser anotado con @Test . Como de costumbre, los métodos de prueba deben ser públicos, no declarar ningún valor de retorno, no tomar parámetros y pueden generar excepciones.

        Context context = InstrumentationRegistry.getTargetContext();

Debido a que el junit4 pruebas ya no requiere una clase base común, que ya no es necesario para obtener Context casos a través de getContext() o getTargetContext() a través de métodos de clase base; en cambio, el nuevo corredor de prueba que los gestiona a través de InstrumentationRegistry donde se almacena la configuración contextual y ambiental creada por el marco de la instrumentación. A través de esta clase, también puede llamar a:

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

Construya y pruebe localmente

Para la mayoría de los casos de uso común, emplean Atest .

Para los casos más complejos que requieren una personalización más pesado, siga las instrucciones de instrumentación .