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. Voir 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. Inclure android_app indiquerait à l'inverse qu'il s'agit plutôt d'un package de construction.
Paramètres
Les paramètres suivants sont expliqués :
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, le test apk 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 indique au système de construction 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 préconstruit pour la bibliothèque AndroidX Test Runner, qui inclut le test runner AndroidJUnitRunner . AndroidJUnitRunner prend en charge le framework de test JUnit4 et a remplacé InstrumentationTestRunner dans Android 10. En savoir plus sur le test des applications Android sur Tester les applications sur Android .
Si vous construisez un nouveau 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 comprend également d'autres cadres de test utiles tels que ub-uiautomator , mockito-target , easymock et plus encore.
certificate: "platform",
Le paramètre certificate indique au système de construction 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 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 vit en dehors du serveur système, c'est-à-dire qu'elle est plus ou moins emballée 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, il est probable que votre instrumentation sera ciblez le package d'application (voir la section ci-dessous sur le manifeste) de votre composant. Dans ce cas, votre fichier makefile d'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 construction le signera simplement avec un certificat intégré par défaut, basé sur la variante de construction, 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 Fédération commerciale. D'autres suites peuvent être ajoutées ici telles que 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 construction que votre cible de test a besoin d'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 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 explicitement défini sur true.
require_root: true
Le paramètre require_root indique au système de génération 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 génération 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 .
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. Voir 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. Inclure android_app indiquerait à l'inverse qu'il s'agit plutôt d'un package de construction.
Paramètres
Les paramètres suivants sont expliqués :
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, le test apk 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 indique au système de construction 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 préconstruit pour la bibliothèque AndroidX Test Runner, qui inclut le test runner AndroidJUnitRunner . AndroidJUnitRunner prend en charge le framework de test JUnit4 et a remplacé InstrumentationTestRunner dans Android 10. En savoir plus sur le test des applications Android sur Tester les applications sur Android .
Si vous construisez un nouveau 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 comprend également d'autres cadres de test utiles tels que ub-uiautomator , mockito-target , easymock et plus encore.
certificate: "platform",
Le paramètre certificate indique au système de construction 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 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 vit en dehors du serveur système, c'est-à-dire qu'elle est plus ou moins emballée 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, il est probable que votre instrumentation sera ciblez le package d'application (voir la section ci-dessous sur le manifeste) de votre composant. Dans ce cas, votre fichier makefile d'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 construction le signera simplement avec un certificat intégré par défaut, basé sur la variante de construction, 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 Fédération commerciale. D'autres suites peuvent être ajoutées ici telles que 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 construction que votre cible de test a besoin d'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 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 explicitement défini sur true.
require_root: true
Le paramètre require_root indique au système de génération 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 génération 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 .
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. Voir 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. Inclure android_app indiquerait à l'inverse qu'il s'agit plutôt d'un package de construction.
Paramètres
Les paramètres suivants sont expliqués :
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, le test apk 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 indique au système de construction 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 préconstruit pour la bibliothèque AndroidX Test Runner, qui inclut le test runner AndroidJUnitRunner . AndroidJUnitRunner prend en charge le framework de test JUnit4 et a remplacé InstrumentationTestRunner dans Android 10. En savoir plus sur le test des applications Android sur Tester les applications sur Android .
Si vous construisez un nouveau 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 comprend également d'autres cadres de test utiles tels que ub-uiautomator , mockito-target , easymock et plus encore.
certificate: "platform",
Le paramètre certificate indique au système de construction 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 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 vit en dehors du serveur système, c'est-à-dire qu'elle est plus ou moins emballée 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, il est probable que votre instrumentation sera ciblez le package d'application (voir la section ci-dessous sur le manifeste) de votre composant. Dans ce cas, votre fichier makefile d'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 construction le signera simplement avec un certificat intégré par défaut, basé sur la variante de construction, 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 Fédération commerciale. D'autres suites peuvent être ajoutées ici telles que 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 construction que votre cible de test a besoin d'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 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 explicitement défini sur true.
require_root: true
Le paramètre require_root indique au système de génération 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 génération 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 .