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 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 una instantánea 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 de 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 para 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 origen de la plataforma también incluye otros frameworks de pruebas útiles, como ub-uiautomator, mockito-target, easymock y mucho 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 debe usarse en los módulos de prueba de CTS. Ten en cuenta que este ejemplo usa este parámetro de configuración de certificado solo a modo de ejemplo: el código de prueba del ejemplo no necesita que el APK de prueba esté firmado con el certificado de plataforma especial.
Si escribes una instrumentación para tu componente que se encuentra fuera del servidor del sistema, es decir, está empaquetado más o menos como un APK de app normal, excepto que está integrado en la imagen del sistema y puede ser una app con privilegios, es probable que tu instrumentación se segmente para el paquete de la app (consulta la sección sobre el manifiesto a continuación) de tu componente. 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 de prueba, el APK de prueba y el APK de la app deben estar firmados 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. Aquí se pueden agregar otros paquetes, como CTS, para que se pueda compartir esta 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"
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 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 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 de 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.