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. Android ahora utiliza el sistema de compilación Soong para una configuración de prueba más sencilla.
Soong utiliza archivos Blueprint o .bp , que son descripciones declarativas simples tipo JSON de los módulos a construir. Este formato reemplaza el sistema basado en Make utilizado en versiones anteriores. Consulte los archivos de referencia de Soong en el Panel de integración continua para obtener detalles completos.
Para realizar pruebas personalizadas o utilizar el conjunto de pruebas de compatibilidad de Android (CTS), siga la Configuración de prueba compleja .
Ejemplo
Las entradas siguientes provienen de este archivo de configuración de Blueprint de ejemplo: /platform_testing/tests/example/instrumentation/Android.bp
Aquí se incluye una instantánea para mayor comodidad:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Tenga en cuenta que la declaración android_test al principio indica que se trata de una prueba. Incluir android_app indicaría, por el contrario, que se trata de un paquete de compilación.
Ajustes
Las siguientes configuraciones obtienen explicación:
name: "HelloWorldTests",
La configuración name es obligatoria cuando se especifica el tipo de módulo android_test (al comienzo del bloque). Le da un nombre a su módulo, y el APK resultante tendrá el mismo nombre y con un sufijo .apk ; por ejemplo, en este caso, el apk de prueba resultante se denomina HelloWorldTests.apk . Además, esto también define un nombre de destino make para su módulo, de modo que pueda usar make [options] <HelloWorldTests> para construir su módulo de prueba y todas sus dependencias.
static_libs: ["androidx.test.runner"],
La configuración static_libs 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 utilizará para resolver referencias de classpath durante el tiempo de compilación, además de incorporarse al apk resultante.
El módulo androidx.test.runner está prediseñado para la biblioteca AndroidX Test Runner, que incluye el ejecutor de pruebas AndroidJUnitRunner . AndroidJUnitRunner es compatible con el marco de prueba JUnit4 y reemplazó InstrumentationTestRunner en Android 10. Obtenga más información sobre cómo probar aplicaciones de Android en Probar aplicaciones en Android .
Si está creando un nuevo módulo de instrumentación, siempre debe comenzar con la biblioteca androidx.test.runner como ejecutor de pruebas. El árbol de fuentes de la plataforma también incluye otros marcos de prueba útiles como ub-uiautomator , mockito-target , easymock y más.
certificate: "platform",
La configuración certificate indica al sistema de compilación que firme el apk con el mismo certificado que la plataforma principal. Esto es necesario si su prueba utiliza un permiso protegido por firma o API. Tenga en cuenta que esto es adecuado para pruebas continuas de plataforma, pero no debe usarse en módulos de prueba CTS. Tenga en cuenta que este ejemplo utiliza esta configuración de certificado solo con fines ilustrativos: en realidad, el código de prueba del ejemplo no necesita que la aplicación de prueba esté firmada con el certificado de plataforma especial.
Si está escribiendo una instrumentación para su componente que se encuentra fuera del servidor del sistema, es decir, está empaquetada más o menos como una aplicación apk normal, excepto que está integrada en la imagen del sistema y puede ser una aplicación privilegiada, es probable que su instrumentación apunte al paquete de la aplicación (consulte la sección siguiente sobre el manifiesto) de su componente. En este caso, el archivo MAKE de su aplicación puede tener su propia configuración certificate y su módulo de instrumentación debe conservar la misma configuración. Esto se debe a que para orientar su instrumentación a la aplicación bajo prueba, su apk de prueba y su apk de aplicación deben estar firmados con el mismo certificado.
En otros casos, no es necesario tener esta configuración en absoluto: el sistema de compilación simplemente lo firmará con un certificado integrado predeterminado, basado en la variante de compilación, y normalmente se denomina dev-keys .
test_suites: ["device-tests"],
La configuración test_suites hace que el arnés de pruebas de la Federación de Comercio pueda descubrir fácilmente la prueba. Se pueden agregar aquí otras suites, como CTS, para que se pueda compartir esta prueba.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Configuraciones opcionales
Las siguientes configuraciones opcionales obtienen explicación:
test_config: "path/to/hello_world_test.xml"
La configuración test_config indica al sistema de compilación que su objetivo de prueba necesita una configuración específica. De forma predeterminada, un AndroidTest.xml junto a Android.bp está asociado con la configuración.
auto_gen_config: true
La 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 establecer este atributo en verdadero de forma explícita.
require_root: true
La configuración require_root 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 root.
test_min_api_level: 29
La configuración test_min_api_level 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, la prueba se omitirá si la propiedad del dispositivo ro.product.first_api_level < test_min_api_level .