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 simplifier configuration de test.
Soong utilise des fichiers Blueprint ou .bp, qui sont de simples fichiers déclaratifs de type JSON
descriptions des modules à compiler. Ce format remplace le système basé sur Make
utilisés 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 classe la suite de test de compatibilité (CTS) Android, suivez les Configuration de test complexe à la place.
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'un build
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. De plus, cela
définit 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 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. 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. Cette étape est nécessaire si votre test utilise une signature
une autorisation protégée ou une API. 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, votre application
que makefile dispose de son propre paramètre certificate, et votre instrumentation
module doivent conserver le même paramètre. En effet, pour cibler
instrumentation sur l'application testée, votre APK et votre APK de test 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 a besoin d'un
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 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é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. Quand échangez
La fédération exécute la configuration du test. Celui-ci sera ignoré si la propriété de l'appareil
sur ro.product.first_api_level < test_min_api_level