Configuration de construction simple

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 maintenant le système de construction Soong pour la configuration de test plus simple.

Soong utilise Blueprint ou .bp fichiers, qui sont JSON comme simples descriptions déclaratives 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 Intégration continue pour plus de détails.

Pour tenir compte des tests personnalisés ou utiliser l'Android Compatibility Test Suite (CTS), suivez la configuration de test complexe à la place.

Exemple

Les entrées sont en dessous de cet exemple fichier de configuration du Plan directeur: /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: ["android-support-test"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

Notez la android_test déclaration au début indique que cela est un test. Y compris android_app serait au contraire l' indiquer est plutôt un ensemble de construction.

Paramètres

Les paramètres suivants sont expliqués :

    name: "HelloWorldTests",

Le name réglage est nécessaire lorsque le android_test type de module est spécifié (au début du bloc). Il donne un nom à votre module, et le résultat APK sera le même nom et avec un .apk suffixe, par exemple dans ce cas, l' APK de test résultant est nommé HelloWorldTests.apk . De plus, cela définit également une marque de nom cible pour votre module, de sorte que vous pouvez utiliser make [options] <HelloWorldTests> pour construire votre module de test et toutes ses dépendances.

    static_libs: ["android-support-test"],

Le static_libs réglage indique au système de construction d'intégrer le contenu des modules nommés dans le apk résultant du module en cours. Cela signifie que chaque module nommé devrait produire un .jar fichier et son contenu seront utilisés pour résoudre les références classpath lors de la compilation, ainsi que incorporé dans le apk résultant.

Dans cet exemple, des choses qui pourraient être généralement utiles pour les tests :

L' android-support-test est le préconstruit pour la bibliothèque support de test Android, qui comprend le nouveau test coureur AndroidJUnitRunner : remplacer le maintenant dépréciée intégré InstrumentationTestRunner , avec le soutien du réseau test junit4. En savoir plus sur les applications de test sur Android .

Si vous construisez un nouveau module d'instrumentation, vous devez toujours commencer par l' android-support-test de bibliothèque comme lanceur de test. L'arbre source de la plate - forme comprend également d' autres frameworks de tests utiles tels que ub-uiautomator , mockito-target , easymock et plus.

    certificate: "platform",

Le certificate paramètre indique au système de construction de signer le apk avec le même certificat que la plate - forme de base. Cela est nécessaire si votre test utilise une autorisation ou une API protégée par signature. Notez que ceci est adapté pour le test continu 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 réside en dehors du serveur système, c'est-à-dire qu'elle est plus ou moins emballée comme un apk d'application ordinaire, 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 cibler le package d'application (voir la section ci-dessous sur le manifeste) de votre composant. Dans ce cas, votre makefile d'application peut avoir son propre certificate réglage, et votre module d'instrumentation doit conserver le même réglage. 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 besoin d'avoir ce paramètre du tout: le système de construction signera simplement avec un défaut intégré certificat, en fonction de la variante de construction, et il est généralement appelé les dev-keys .

    test_suites: ["device-tests"],

Le test_suites paramètre fait le test facilement découvrable par le harnais de test Fédération du commerce. 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 sont expliqués :

    test_config: "path/to/hello_world_test.xml"

Le test_config paramètre indique le système de construction de votre cible de test a besoin d' une configuration spécifique. Par défaut, un AndroidTest.xml à côté du Android.bp est associée à la configuration.

    auto_gen_config: true

Le auto_gen_config paramètre indique si oui ou non pour créer la configuration de test automatique. Si AndroidTest.xml n'existe pas à côté de la Android.bp , cet attribut n'a pas besoin d'être définie sur true explicitement.

    require_root: true

Le require_root paramètre indique au système de construction d'ajouter RootTargetPreparer à la configuration de test généré automatique. Cela garantit que le test s'exécute avec les autorisations root.

    test_min_api_level: 29

Le test_min_api_level paramètre indique au système de construction d'ajouter MinApiLevelModuleController à la configuration de test généré automatique. Lorsque la Fédération du Commerce exécute la configuration de test, le test est sautée si la propriété de l' appareil de ro.product.first_api_level < test_min_api_level .