Cada módulo de prueba nuevo debe tener un archivo de configuración para dirigir el sistema de compilación con metadatos del módulo, instrucciones de empaquetado y dependencias de tiempo de compilación. Android ahora utiliza el sistema de compilación Soong para ofrecer configuración de prueba.
Soong usa archivos Blueprint o .bp, que son declarativos simples y similares a JSON
descripciones de los módulos que se compilarán. Este formato reemplaza al sistema basado en Make
que se usaron en versiones anteriores. Consulta los archivos de referencia de Soong.
en el Panel de integración continua para obtener todos los detalles.
Para admitir pruebas personalizadas o usar la Conjunto de pruebas de compatibilidad (CTS) de Android, sigue Configuración de prueba compleja en su lugar.
Ejemplo
Las siguientes entradas provienen de este archivo de configuración de esquema de ejemplo: /platform_testing/tests/example/instrumentation/Android.bp
Aquí se incluye un resumen para tu comodidad:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Ten en cuenta que la declaración android_test al comienzo indica que se trata de una prueba.
Incluir android_app indicaría, en cambio, que se trata de una compilación.
.
Configuración
La siguiente configuración proporciona una explicación:
name: "HelloWorldTests",
El parámetro de configuración name es obligatorio cuando se especifica el tipo de módulo android_test
(al comienzo del bloque). Le asigna un nombre a tu módulo, y la
El APK tendrá el mismo nombre y con un sufijo .apk, p.ej., En este caso,
El APK de la prueba resultante se llama HelloWorldTests.apk. Además, esto también
define un nombre de destino para tu módulo, de modo que puedas usar make [options]
<HelloWorldTests> para compilar el módulo de prueba y todas sus dependencias.
static_libs: ["androidx.test.runner"],
El parámetro de configuración static_libs le indica al sistema de compilación que incorpore el contenido.
de los módulos nombrados en el APK resultante del módulo actual. Esto significa que
Se espera que cada módulo con nombre produzca un archivo .jar, y su contenido se
que se usan para resolver referencias de rutas de clase durante el tiempo de compilación, así como
incorporada en el APK resultante.
El módulo androidx.test.runner es la compilación previa para AndroidX Test Runner
Biblioteca, que incluye el ejecutor de pruebas AndroidJUnitRunner
AndroidJUnitRunner es compatible con el framework de prueba de JUnit4 y se reemplazó.
InstrumentationTestRunner en Android 10 Más información
sobre cómo probar apps para Android en Cómo probar apps en Android.
Si estás compilando un nuevo módulo de instrumentación,
la biblioteca androidx.test.runner como ejecutor de pruebas El árbol fuente de la plataforma
también incluye otros frameworks de prueba útiles, como ub-uiautomator,
mockito-target, easymock y otros
certificate: "platform",
El parámetro de configuración certificate le indica al sistema de compilación que firme el APK con el mismo
certificado como la plataforma principal. Esto es necesario si la prueba usa una firma
una API o un permiso protegido. Ten en cuenta que esto es adecuado para la administración
pruebas, pero no debe usarse en los módulos de prueba de CTS. Ten en cuenta que este ejemplo
usa esta configuración de certificado solo con fines ilustrativos: el código de prueba.
del ejemplo no necesita realmente que el APK de prueba se firme con el
certificado especial de plataforma.
Si escribes una instrumentación para tu componente que se encuentra fuera de
es decir, se empaqueta más o menos
como el apk de una app normal,
salvo que está integrada en la imagen del sistema
y puede ser una aplicación con privilegios,
es que tu instrumentación se orientará al paquete de app (consulta a continuación
(sección sobre el manifiesto) de tu componente. En este caso, tu aplicación
Makefile puede tener su propia configuración de certificate, y tu instrumentación
debería conservar la misma configuración. Esto se debe a que segmentar tus anuncios para
la instrumentación en la app que se está probando, tu APK de prueba y el de la app deben estar firmados
con el mismo certificado.
En otros casos, no necesitas tener
esta configuración: el sistema de compilación
lo firmará con un certificado integrado predeterminado basado en el
que, por lo general, se llama dev-keys.
test_suites: ["device-tests"],
El parámetro de configuración test_suites hace que la prueba sea fácil de encontrar para el comercio
Agente de prueba de federación. Aquí se pueden agregar otros paquetes, como CTS, para que esta
es posible que se comparta la prueba.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Configuración opcional
La siguiente configuración opcional proporciona una explicación:
test_config: "path/to/hello_world_test.xml"
El parámetro de configuración test_config le indica al sistema de compilación que tu destino de prueba necesita un
configuración específica. De forma predeterminada, se muestra un AndroidTest.xml junto a Android.bp
asociada con la configuración.
auto_gen_config: true
El parámetro de configuración auto_gen_config indica si se debe crear la configuración de prueba o no
automáticamente. Si AndroidTest.xml no existe junto a Android.bp, este valor
no es necesario establecerlo explícitamente como verdadero.
require_root: true
El parámetro de configuración require_root le indica al sistema de compilación que agregue RootTargetPreparer.
a la configuración de prueba generada automáticamente. Esto garantiza que la prueba se ejecute con la raíz
permisos.
test_min_api_level: 29
El parámetro de configuración test_min_api_level le indica al sistema de compilación que agregue
MinApiLevelModuleController a la configuración de prueba generada automáticamente. Cuando operas
La federación ejecuta la configuración de la prueba; esta se omitirá si la propiedad del dispositivo
de ro.product.first_api_level < test_min_api_level