Chaque nouveau module de test doit disposer d'un fichier de configuration pour diriger le système de compilation avec les métadonnées du module, les dépendances au moment de la compilation et les instructions de packaging. Android utilise désormais le système de compilation Soong pour une configuration de test plus simple.
Soong utilise des fichiers Blueprint ou .bp, qui sont des descriptions déclaratives simples de modules à compiler, semblables à JSON. Ce format remplace le système basé sur Make utilisé dans les versions précédentes. Pour en savoir plus, consultez les fichiers de référence Soong sur le tableau de bord d'intégration continue.
Pour effectuer des tests personnalisés ou utiliser la suite de tests de compatibilité (CTS) Android, suivez plutôt la configuration de test complexe.
Exemple
Les entrées ci-dessous proviennent de cet exemple de fichier de configuration Blueprint : /platform_testing/tests/example/instrumentation/Android.bp
Pour plus de commodité, un instantané est inclus:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Notez que la déclaration android_test au début indique qu'il s'agit d'un test.
Inclure android_app indiquerait à l'inverse qu'il s'agit d'un package de compilation.
Paramètres
Les paramètres suivants nécessitent une explication:
name: "HelloWorldTests",
Le paramètre name est requis lorsque le type de module android_test est spécifié (au début du bloc). Il donne un nom à votre module, et l'APK généré portera le même nom avec un suffixe .apk. Par exemple, dans ce cas, l'APK de test généré est nommé HelloWorldTests.apk. En outre, cela définit également un nom de cible de création pour votre module, afin que vous puissiez utiliser make [options]
<HelloWorldTests> pour créer votre module de test et toutes ses dépendances.
static_libs: ["androidx.test.runner"],
Le paramètre static_libs indique au système de compilation d'intégrer le contenu des modules nommés dans l'APK généré du module actuel. Cela signifie que chaque module nommé doit produire un fichier .jar, et que son contenu sera utilisé pour résoudre les références de chemin d'accès au moment de la compilation, ainsi que pour être intégré à l'APK généré.
Le module androidx.test.runner est prédéfini pour la bibliothèque AndroidX Test Runner, qui inclut l'exécuteur de test AndroidJUnitRunner.
AndroidJUnitRunner est compatible avec le framework de test JUnit4 et a remplacé InstrumentationTestRunner dans Android 10. Pour en savoir plus sur le test des applications Android, consultez Tester des applications sur Android.
Si vous créez un nouveau module d'instrumentation, vous devez toujours commencer par la bibliothèque androidx.test.runner comme outil de test. L'arborescence source de la plate-forme inclut également d'autres frameworks de test utiles tels que ub-uiautomator, mockito-target, easymock, etc.
certificate: "platform",
Le paramètre certificate indique au système de compilation de signer l'APK avec le même certificat que la plate-forme de base. Cette étape est nécessaire si votre test utilise une autorisation ou une API protégée par signature. Notez que cette méthode convient aux tests continus de la plate-forme, mais ne doit pas être utilisée dans les modules de test CTS. Notez que cet exemple n'utilise ce paramètre de certificat qu'à des fins d'illustration: le code de test de l'exemple n'a pas besoin que l'APK de test soit signé avec le certificat de plate-forme spécial.
Si vous écrivez une instrumentation pour votre composant qui se trouve en dehors du serveur système, c'est-à-dire qu'il est empaqueté plus ou moins comme un APK d'application standard, à l'exception qu'il est intégré à l'image système et peut être une application privilégiée, il est probable que votre instrumentation cible le package d'application (voir la section sur le fichier manifeste ci-dessous) de votre composant. Dans ce cas, le fichier de compilation de votre application peut avoir son propre paramètre certificate, et votre module d'instrumentation doit conserver le même paramètre. En effet, pour cibler votre instrumentation sur l'application en cours de test, votre APK de test et l'APK de l'application doivent être signés avec le même certificat.
Dans d'autres cas, ce paramètre n'est pas nécessaire: le système de compilation le signe simplement avec un certificat intégré par défaut, basé sur la variante de compilation, et il est généralement appelé dev-keys.
test_suites: ["device-tests"],
Le paramètre test_suites permet au harnais de test de la fédération du commerce de trouver facilement le test. Vous pouvez ajouter d'autres suites ici, comme CTS, afin que ce test puisse être partagé.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Paramètres facultatifs
Les paramètres facultatifs suivants nécessitent une explication:
test_config: "path/to/hello_world_test.xml"
Le paramètre test_config indique au système de compilation que votre cible de test nécessite une configuration spécifique. Par défaut, un AndroidTest.xml à côté de Android.bp est associé à la configuration.
auto_gen_config: true
Le paramètre auto_gen_config indique si la configuration de test doit être créée automatiquement ou non. Si AndroidTest.xml n'existe pas à côté de Android.bp, cet attribut n'a pas besoin d'être défini explicitement sur "true".
require_root: true
Le paramètre require_root indique au système de compilation d'ajouter RootTargetPreparer à la configuration de test générée automatiquement. Cela garantit que le test s'exécute avec des autorisations racine.
test_min_api_level: 29
Le paramètre test_min_api_level indique au système de compilation d'ajouter MinApiLevelModuleController à la configuration de test générée automatiquement. Lorsque la fédération commerciale exécute la configuration de test, celui-ci est ignoré si la propriété de l'appareil ro.product.first_api_level est inférieure à test_min_api_level.