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 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 para compilar. Este formato reemplaza el sistema basado en Make utilizado en versiones anteriores. Consulte los archivos de referencia de Soong en el panel de control de integración continua para obtener detalles completos.
Para adaptarse a las pruebas personalizadas o usar el conjunto de pruebas de compatibilidad de Android (CTS), siga la Configuración de prueba compleja en su lugar.
Ejemplo
Las siguientes entradas provienen de este archivo de configuración Blueprint de ejemplo: /platform_testing/tests/example/instrumentation/Android.bp
Se incluye una instantánea aquí para mayor comodidad:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["android-support-test"],
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 , por el contrario, que se trata de un paquete de compilación.
Ajustes
La siguiente configuración obtiene una explicación:
name: "HelloWorldTests",
La configuración del name es necesaria 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 un sufijo .apk , por ejemplo, en este caso, el apk de prueba resultante se llamará HelloWorldTests.apk . Además, esto también define un nombre de destino de creación para su módulo, de modo que puede usar make [options] <HelloWorldTests> para construir su módulo de prueba y todas sus dependencias.
static_libs: ["android-support-test"],
La configuración de 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 nombrado produzca un archivo .jar , y su contenido se usará para resolver las referencias de classpath durante el tiempo de compilación, así como también se incorporará al apk resultante.
En este ejemplo, las cosas que pueden ser generalmente útiles para las pruebas:
android-support-test es el precompilado para la biblioteca de soporte de prueba de Android, que incluye el nuevo ejecutor de prueba AndroidJUnitRunner : un reemplazo para el InstrumentationTestRunner incorporado ahora obsoleto, con soporte para el marco de prueba JUnit4. Obtenga más información en Probar aplicaciones en Android .
Si está creando un nuevo módulo de instrumentación, siempre debe comenzar con la biblioteca android-support-test como ejecutor de pruebas. El árbol de fuentes de la plataforma también incluye otros marcos de prueba útiles, como ub-uiautomator uiautomator, mockito-target , easymock y más.
certificate: "platform",
La configuración del 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 una API o un permiso protegido por firma. 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 usa esta configuración de certificado solo con fines ilustrativos: el código de prueba del ejemplo en realidad no necesita que el apk de prueba esté firmado 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 un apk de aplicación regular, excepto que está integrado en la imagen del sistema y puede ser una aplicación privilegiada, es probable que su instrumentación tenga como objetivo el paquete de la aplicación (consulte la sección a continuación sobre el manifiesto) de su componente. En este caso, el archivo MAKE de su aplicación puede tener su propia configuración de certificate y su módulo de instrumentación debe conservar la misma configuración. Esto se debe a que, para orientar su instrumentación en la aplicación que se está probando, su apk de prueba y el apk de la aplicación deben estar firmados con el mismo certificado.
En otros casos, no necesita 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 llama dev-keys .
test_suites: ["device-tests"],
La configuración de test_suites hace que el arnés de prueba de la Federación de Comercio detecte fácilmente la prueba. Aquí se pueden agregar otras suites, como CTS, para que esta prueba se pueda compartir.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Configuraciones opcionales
Las siguientes configuraciones opcionales obtienen una explicación:
test_config: "path/to/hello_world_test.xml"
La configuración test_config le 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 crear o no la configuración de prueba automáticamente. Si AndroidTest.xml no existe junto a Android.bp , no es necesario establecer explícitamente este atributo en verdadero.
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 de ro.product.first_api_level < test_min_api_level .