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 del tiempo de compilación. Android ahora usa el sistema de compilación de Soong para una configuración de prueba más simple.
Soong usa archivos Blueprint o .bp, que son descripciones declarativas simples similares a JSON de los módulos que se compilarán. Este formato reemplaza el sistema basado en Make que se usaba 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 el Conjunto de pruebas de compatibilidad (CTS) de Android, sigue la configuración de pruebas complejas.
Ejemplo
Las siguientes entradas provienen de este ejemplo de archivo de configuración de Blueprint: /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.
Si incluyes android_app, se indicaría que se trata de un paquete de compilación.
Configuración
A continuación, se explica la siguiente configuración:
name: "HelloWorldTests",
La configuración name es obligatoria cuando se especifica el tipo de módulo android_test (al comienzo del bloque). Le asigna un nombre a tu módulo, y el APK resultante tendrá el mismo nombre y un sufijo .apk. Por ejemplo, en este caso, el APK de prueba resultante se llama HelloWorldTests.apk. Además, también define un nombre de destino de make para tu módulo, de modo que puedas usar make [options]
<HelloWorldTests> para compilar tu módulo de prueba y todas sus dependencias.
static_libs: ["androidx.test.runner"],
La configuración de 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 nombrado produzca un archivo .jar, y su contenido se usará para resolver referencias de classpath durante el tiempo de compilación, además de incorporarse al apk resultante.
El módulo androidx.test.runner es el compilado previamente para la biblioteca de AndroidX Test Runner, que incluye el panel de prueba AndroidJUnitRunner.
AndroidJUnitRunner admite el framework de pruebas JUnit4 y reemplazó a InstrumentationTestRunner en Android 10. Obtén más información sobre cómo probar apps para Android en Cómo probar apps en Android.
Si compilas un nuevo módulo de instrumentación, siempre debes comenzar con la biblioteca androidx.test.runner como ejecutor de pruebas. El árbol de fuentes de la plataforma también incluye otros frameworks de pruebas útiles, como ub-uiautomator, mockito-target, easymock y más.
certificate: "platform",
La configuración de certificate le indica al sistema de compilación que firme el APK con el mismo certificado que 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 las pruebas continuas de la plataforma, pero no se debe usar en los módulos de prueba del CTS. Ten en cuenta que, en este ejemplo, se usa esta configuración de certificado solo con fines ilustrativos: el código de prueba del ejemplo no necesita que se firme el APK de prueba con el certificado especial de plataforma.
Si escribes una instrumentación para tu componente que se encuentra fuera del servidor del sistema, es decir, se empaqueta más o menos como un APK de app normal, excepto que está integrada en una imagen del sistema y puede ser una app con privilegios, lo más probable es que tu instrumentación se oriente al paquete de apps de tu componente (consulta la siguiente sección sobre el manifiesto). En este caso, el archivo de configuración de compilación de tu aplicación puede tener su propia configuración de certificate, y tu módulo de instrumentación debe conservar la misma configuración. Esto se debe a que, para orientar tu instrumentación en la app que estás probando, el APK de prueba y el de la app deben firmarse con el mismo certificado.
En otros casos, no es necesario que tengas este parámetro de configuración: el sistema de compilación solo lo firmará con un certificado integrado predeterminado, según la variante de compilación, y, por lo general, se lo denomina dev-keys.
test_suites: ["device-tests"],
La configuración de test_suites permite que el conjunto de pruebas de Trade Federation descubra fácilmente la prueba. Se pueden agregar otros paquetes aquí, como CTS, de modo que esta prueba se pueda compartir.
${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"
La configuración test_config le indica al sistema de compilación que tu destino de prueba necesita una configuración específica. De forma predeterminada, se asocia un AndroidTest.xml junto a Android.bp con la configuración.
auto_gen_config: true
El parámetro de configuración auto_gen_config indica si se debe crear o no la configuración de prueba
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 permisos de raíz.
test_min_api_level: 29
La 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 Trade Federation ejecuta la configuración de prueba, se omite la prueba si la propiedad del dispositivo de ro.product.first_api_level < test_min_api_level.