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 de compilation et les instructions d'empaquetage. Android utilise désormais le système de compilation Soong pour simplifier la configuration des tests.
Soong utilise des fichiers Blueprint ou .bp, qui sont des descriptions déclaratives simples de type JSON des modules à compiler. 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 Compatibility Test Suite (CTS) Android, suivez plutôt Configuration de tests complexes.
Exemple
Les entrées ci-dessous proviennent de cet exemple de fichier de configuration Blueprint : /platform_testing/tests/example/instrumentation/Android.bp
Un instantané est inclus ici pour plus de commodité :
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.
L'inclusion de 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 obligatoire lorsque le type de module android_test est spécifié (au début du bloc). Il donne un nom à votre module.L'APK résultant portera le même nom avec le suffixe .apk. Par exemple, dans ce cas, l'APK de test résultant est nommé HelloWorldTests.apk. Cela définit également un nom de cible Make pour votre module, afin que vous puissiez utiliser make [options]
<HelloWorldTests> pour compiler 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 résultant du module actuel. Cela signifie que chaque module nommé est censé produire un fichier .jar, et que son contenu sera utilisé pour résoudre les références du chemin de classe lors de la compilation, ainsi que pour être intégré à l'APK résultant.
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 module d'instrumentation, vous devez toujours commencer par la bibliothèque androidx.test.runner comme exécuteur 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 principale. Cette étape est nécessaire si votre test utilise une autorisation ou une API protégée par une signature. Notez que cela convient aux tests continus de la plate-forme, mais ne doit pas être utilisé dans les modules de test CTS. Notez que cet exemple utilise ce paramètre de certificat uniquement à des fins d'illustration : le code de test de l'exemple n'a pas réellement 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 du fait qu'il est intégré à l'image système et peut être une application privilégiée, il y a de fortes chances que votre instrumentation cible le package d'application (voir la section ci-dessous sur le fichier manifeste) de votre composant. Dans ce cas, le fichier makefile 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 votre APK d'application doivent être signés avec le même certificat.
Dans d'autres cas, vous n'avez pas besoin de ce paramètre : le système de compilation le signera simplement avec un certificat intégré par défaut, en fonction de la variante de compilation. Il est généralement appelé dev-keys.
test_suites: ["device-tests"],
Le paramètre test_suites permet au harnais de test Trade Federation de découvrir facilement le test. D'autres suites peuvent être ajoutées 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 s'il faut créer la configuration de test automatiquement ou non. Si AndroidTest.xml n'existe pas à côté de Android.bp, il n'est pas nécessaire de définir explicitement cet attribut 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 les autorisations root.
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 Trade Federation exécute la configuration de test, le test est ignoré si la propriété de l'appareil ro.product.first_api_level est inférieure à test_min_api_level.