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. Consultez les fichiers de référence Soong
dans 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 de plan: /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.
Inversement, inclure android_app indiquerait qu'il s'agit plutôt d'une compilation
d'un package.
Paramètres
Les paramètres suivants fournissent des explications:
name: "HelloWorldTests",
Le paramètre name est obligatoire lorsque le type de module android_test est spécifié.
(au début du bloc). Elle attribue un nom à votre module. Le résultat
L'APK portera le même nom avec le suffixe .apk, par exemple dans ce cas,
L'APK de test résultant est nommé HelloWorldTests.apk. En outre, cela définit également un nom de cible de compilation 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é doit générer un fichier .jar, dont le contenu est
utilisé pour résoudre les références au classpath au moment de la compilation, ainsi que
incorporé dans l'APK résultant.
Le module androidx.test.runner est prédéfini pour AndroidX Test Runner.
Bibliothèque, qui inclut l'exécuteur de test AndroidJUnitRunner.
AndroidJUnitRunner est compatible avec le framework de test JUnit4 et a remplacé
InstrumentationTestRunner sur Android 10. En savoir plus
pour tester 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 en tant qu'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 demande au système de compilation de signer l'APK avec la même
de certification en tant
que plate-forme principale. Cela est nécessaire si votre test utilise une autorisation ou une API protégée par signature. Notez que cela convient au cas d'utilisation continue de plate-forme.
tests, mais ne doivent pas être utilisées 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 besoin que l'APK test soit signé avec
un certificat spécial de
plateforme.
Si vous écrivez pour votre composant une instrumentation qui existe en dehors de
serveur système, c'est-à-dire qu'il est empaqueté
plus ou moins comme un APK d'application standard,
sauf qu'elle est intégrée à l'image système
et peut être une application privilégiée,
que votre instrumentation ciblera le package d'application (voir ci-dessous
sur le fichier manifeste) 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
Google le signera simplement avec un certificat intégré par défaut, basé sur le build
et est généralement appelé dev-keys.
test_suites: ["device-tests"],
Le paramètre test_suites rend le test facile à détecter par l'équipe
Test de la fédération. D'autres suites, comme CTS, peuvent être ajoutées ici.
peut être partagé.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Paramètres facultatifs
Les paramètres facultatifs suivants fournissent 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ées à la configuration.
auto_gen_config: true
Le paramètre auto_gen_config indique si la configuration de test doit être créée ou non.
automatiquement. Si AndroidTest.xml n'apparaît pas à côté de Android.bp, cette
n'a pas besoin d'être explicitement défini 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écutera avec root
autorisations.
test_min_api_level: 29
Le paramètre test_min_api_level demande 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.