Chaque nouveau module de test doit avoir un fichier de configuration pour diriger le système de construction avec les métadonnées du module, les dépendances au moment de la compilation et les instructions d'empaquetage. Android utilise désormais le système de construction Soong pour une configuration de test plus simple.
Soong utilise des fichiers Blueprint ou .bp , qui sont de simples descriptions déclaratives de type JSON des modules à construire. Ce format remplace le système basé sur Make utilisé dans les versions précédentes. Consultez les fichiers de référence Soong sur le tableau de bord d'intégration continue pour plus de détails.
Pour effectuer des tests personnalisés ou utiliser la suite de tests de compatibilité Android (CTS), 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
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 plutôt d'un package de construction.
Paramètres
Les paramètres suivants donnent lieu à des explications :
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 résultant sera nommé de la même manière et avec un suffixe .apk , par exemple dans ce cas, l'apk de test résultant est nommé HelloWorldTests.apk . De plus, cela définit également un nom de cible make pour votre module, afin que vous puissiez utiliser make [options] <HelloWorldTests> pour construire votre module de test et toutes ses dépendances.
static_libs: ["androidx.test.runner"],
Le paramètre static_libs demande au système de build d'incorporer 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 de chemin de classe pendant la compilation, ainsi qu'incorporé dans l'apk résultant.
Le module androidx.test.runner est le module prédéfini pour la bibliothèque AndroidX Test Runner, qui inclut le programme d'exécution de test AndroidJUnitRunner . AndroidJUnitRunner prend en charge le framework de test JUnit4 et a remplacé InstrumentationTestRunner dans Android 10. Pour en savoir plus sur les tests d'applications Android, consultez Test apps on Android .
Si vous créez un nouveau module d'instrumentation, vous devez toujours commencer avec la bibliothèque androidx.test.runner comme exécuteur de test. L'arborescence des sources de la plateforme comprend également d'autres frameworks de test utiles tels que ub-uiautomator , mockito-target , easymock et plus encore.
certificate: "platform",
Le paramètre certificate demande au système de build de signer l'apk avec le même certificat que la plate-forme principale. Ceci est nécessaire si votre test utilise une autorisation ou une API protégée par signature. Notez que cela convient aux tests continus de la plateforme, 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 réside en dehors du serveur système, c'est-à-dire qu'elle est packagée plus ou moins comme une application apk classique, sauf qu'elle est intégrée à l'image système et peut être une application privilégiée, il y a de fortes chances que votre instrumentation le fasse. cibler le package d'application (voir la section ci-dessous sur le manifeste) de votre composant. Dans ce cas, le 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 testée, 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 du tout besoin d'avoir ce paramètre : le système de build le signera simplement avec un certificat intégré par défaut, basé sur la variante de build, et il est généralement appelé dev-keys .
test_suites: ["device-tests"],
Le paramètre test_suites rend le test facilement détectable par le harnais de test de la Trade Federation. D'autres suites peuvent être ajoutées ici comme CTS pour que ce test puisse être partagé.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Paramètres facultatifs
Les paramètres facultatifs suivants donnent lieu à des explications :
test_config: "path/to/hello_world_test.xml"
Le paramètre test_config indique au système de build que votre cible de test a besoin d'une configuration spécifique. Par défaut, un AndroidTest.xml à côté du Android.bp est associé à la configuration.
auto_gen_config: true
Le paramètre auto_gen_config indique s’il faut ou non créer automatiquement la configuration de test. 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 demande au système de build d'ajouter RootTargetPreparer à la configuration de test générée automatiquement. Cela garantit que le test s'exécutera avec les autorisations root.
test_min_api_level: 29
Le paramètre test_min_api_level demande au système de build d'ajouter MinApiLevelModuleController à la configuration de test générée automatiquement. Lorsque Trade Federation exécute la configuration de test, le test sera ignoré si la propriété de périphérique de ro.product.first_api_level < test_min_api_level .