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 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 principio 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 API o un permiso protegido con firma. 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
del sistema de archivos, es decir, se empaqueta más o menos como un APK normal de la app,
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
instrumentación en la app que se está probando, se deben firmar los APK de prueba y de app
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
A continuación, se explica la siguiente configuración opcional:
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 asocia un AndroidTest.xml junto al Android.bp 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, no es necesario configurar este atributo como verdadero de forma explícita.
require_root: true
La 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