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

Ejemplo de pruebas de autoinstrucción

Cuando se inicia una prueba de instrumentación, su paquete de destino se reinicia con el código de instrumentación inyectado y se inicia para su ejecución. Una excepción es que el paquete objetivo aquí no puede ser el marco de aplicaciones Android en sí, es decir, el paquete android , porque hacerlo daría lugar a la situación paradójica donde tendría que ser reiniciado marco de Android, que es lo que es compatible con las funciones del sistema, incluyendo la instrumentación sí mismo.

Esto significa que una prueba de instrumentación no puede inyectarse en el marco de Android, también conocido como servidor del sistema, para su ejecución. Con el fin de probar el marco de Android, el código de prueba puede invocar superficies API única públicos, o los que están expuestos través de la interfaz de Android lenguaje de definición de AIDL disponibles en el árbol de código fuente de la plataforma. Para esta categoría de pruebas, no tiene sentido apuntar a ningún paquete en particular. Por lo tanto, es habitual para tales instrumentaciones que se declare para orientar su propio paquete de aplicación de prueba, tal como se define en su propio <manifest> etiqueta de AndroidManifest.xml .

Dependiendo de los requisitos, los paquetes de aplicaciones de prueba de esta categoría también pueden:

  • Agrupe las actividades necesarias para las pruebas.
  • Comparta la identificación de usuario con el sistema.
  • Estar firmado con la clave de la plataforma.
  • Se compila con la fuente del marco en lugar del SDK público.

Esta categoría de pruebas de instrumentación a veces se denomina autoinstrumentación. A continuación, se muestran algunos ejemplos de pruebas de autoinstrumentación en la fuente de la plataforma:

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. Esta guía utiliza la siguiente prueba como ejemplo:

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

Decidir una ubicación de origen

Por lo general, su equipo ya tendrá un patrón establecido de lugares para registrar el código y lugares para agregar pruebas. La mayoría de los equipos poseen un único repositorio de git, o comparten uno con otros equipos, pero tienen un subdirectorio dedicado que contiene el código fuente de los componentes.

Suponiendo que la ubicación raíz de su fuente componente es en <component source root> mayoría de los componentes tienen src y tests carpetas debajo de él, y algunos archivos adicionales, tales como Android.mk (o divide en adicionales .mk archivos), el archivo de manifiesto AndroidManifest.xml , y el archivo de configuración de prueba 'AndroidTest.xml'.

Puesto que usted está agregando una nueva prueba de la marca, es probable que necesite para crear la tests directorio junto a su componente src , y rellenarla con el contenido.

En algunos casos, su equipo podría tener otras estructuras de directorios bajo tests debido a la necesidad de empaquetar diferentes suites de pruebas en un apk individuales. Y en este caso, tendrá que crear un nuevo subdirectorio bajo tests .

Independientemente de la estructura, que va a terminar poblando la tests directorio o subdirectorio recién creado con archivos similares a lo que hay en instrumentation de directorio en el cambio Gerrit muestra. Las secciones siguientes explicarán con más detalle cada archivo.

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 módulo de prueba, 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. Vea el ejemplo en platform_testing / pruebas / ejemplo / instrumentación / AndroidManifest.xml .

Aquí se incluye una instantánea para mayor comodidad:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >

    <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="21" />

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

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
                     android:targetPackage="android.test.example.helloworld"
                     android:label="Hello World Test"/>

</manifest>

Algunas observaciones selectas sobre el archivo de manifiesto:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >

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.

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.

android:sharedUserId="android.uid.system"

Esto declara que en el momento de la instalación, a este apk se le debe otorgar la misma identificación de usuario, es decir, identidad en tiempo de ejecución, que la plataforma central. Tenga en cuenta que esto depende de la apk de ser firmado con el mismo certificado como la plataforma central (ver LOCAL_CERTIFICATE en la sección anterior), sin embargo, son diferentes conceptos:

  • algunos permisos o API están protegidos por firmas, lo que requiere el mismo certificado de firma
  • algunos permisos o API requiere que el system identidad de usuario de la persona que llama, que requiere el paquete llamando a la cuota de identificación del usuario con system , si es un paquete separado de la plataforma propio núcleo
<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="android.test.example.helloworld"

Usted puede haber notado que la targetPackage aquí se declara el mismo que el package atributo declarado en el manifest la etiqueta de este archivo. Como se mencionó en lo básico de pruebas , esta categoría de instrumentación de prueba están destinados normalmente para probar API marco, así que no es muy significativo para ellos tener un paquete de aplicaciones dirigidas específicas, aparte de sí mismo.

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. Para más detalles, consulte Configuración de prueba simple .

Archivo de configuración complejo

Para estos casos más complejos, 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. Vea el ejemplo en /platform_testing/tests/example/instrumentation/AndroidTest.xml .

Aquí se incluye una instantánea para mayor comodidad:

<configuration description="Runs sample instrumentation test.">
  <target_preparer class="com.android.tradefed.targetprep.TestFilePushSetup"/>
  <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
    <option name="test-file-name" value="HelloWorldTests.apk"/>
  </target_preparer>
  <target_preparer class="com.android.tradefed.targetprep.PushFilePreparer"/>
  <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer"/>
  <option name="test-suite-tag" value="apct"/>
  <option name="test-tag" value="SampleInstrumentationTest"/>

  <test class="com.android.tradefed.testtype.AndroidJUnitTest">
    <option name="package" value="android.test.example.helloworld"/>
    <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="HelloWorldTests.apk"/>
</target_preparer>

Esto le dice a Trade Federation que instale HelloWorldTests.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="android.test.example.helloworld"/>
  <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.

Para obtener más información, véase el módulo de prueba Config .

Funciones de JUnit4

El uso android-support-test biblioteca como corredor de prueba permite la adopció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. Vea el ejemplo en /platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.java .

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

@RunWith(JUnit4.class)
public class HelloWorldTest {

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

    @BeforeClass
    public static void beforeClass() {
    ...
    @AfterClass
    public static void afterClass() {
    ...
    @Before
    public void before() {
    ...
    @After
    public void after() {
    ...
    @Test
    @SmallTest
    public void testHelloWorld() {
    ...

Los @Before y @After anotaciones se utilizan en los métodos de junit4 para llevar a cabo configuración de prueba pre y prueba de desmontaje posterior. Del mismo modo, los @BeforeClass y @AfterClass anotaciones se utilizan en los métodos de junit4 a realizar la configuración antes de ejecutar todas las pruebas en una clase de prueba, desmontaje y 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.

Importante: los métodos de prueba a sí mismos están anotados con @Test anotación; y nota que para las pruebas que se ejecutarán a través de APCT, deben ser anotados con tamaños de prueba: el ejemplo anotado método testHelloWorld como @SmallTest . La anotación se puede aplicar al alcance del método o al alcance de la clase.

Acceso a instrumentation

Aunque no entra en el ejemplo básico hola mundo, es bastante común para una prueba de Android para requerir el acceso Instrumentation ejemplo: esta es la interfaz API central que proporciona acceso a los contextos de aplicación, relacionados con el ciclo de vida API prueba la actividad y más.

Debido a que el junit4 prueba ya no se requiere una clase base común, que ya no es necesario obtener Instrumentation ejemplo a través de InstrumentationTestCase#getInstrumentation() , en cambio, el nuevo corredor de prueba lo gestiona a través de InstrumentationRegistry donde se almacena la configuración contextual y ambiental creada por el marco de la instrumentación.

Para acceder a la instancia de Instrumentation de clase, sólo tiene que llamar método estático getInstrumentation() en InstrumentationRegistry clase:

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

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 .