Modules de test

Cette page fournit des informations de base sur la façon de créer un module rust_test qui utilise le harnais de test Rust.

Écrire un test Rust de base

Pour un exemple en direct d'un test Rust sur l'appareil et sur l'hôte, consultez keystore2 Android.bp ou localisez-en un parmi de nombreuses caisses dans le répertoire external/rust/crates .

Un module rust_test est construit en utilisant l'indicateur --test de rustc, qui crée des tests à partir du code marqué avec l'attribut #[test] . Pour plus d’informations, consultez la documentation sur les attributs de test de référence Rust .

Définissez un module de test comme suit :

rust_test {
    name: "libfoo_inline_tests",

    // Specify the entry point of your library or binary to run all tests
    // specified in-line with the test attribute.
    srcs: ["src/lib.rs"],

    // Tradefed test suite to include this test in.
    test_suites: ["general-tests"],

    // Autogenerate the test config
    auto_gen_config: true,

    rustlibs: [
        "libfoo",
    ],
}

Un fichier TEST_MAPPING contient une liste de tests. Bien que ce ne soit pas une exigence, si vous créez un fichier TEST_MAPPING, les tests que vous y incluez s'exécuteront dans les tests de pré-soumission et pourront être invoqués à l'aide atest .

Vous pouvez référencer la documentation TEST_MAPPING pour plus d'informations, mais pour l'exemple libfoo_inline_tests , ajoutez ceci à la pré-soumission pour activer vos exécutions de tests sur TreeHugger :

{
  "presubmit": [
    {
      "name": "libfoo_inline_tests",
    },
  ]
}

Notez que les modules rust_test_host s'exécutent par défaut dans presubmit sauf si unit_tests: est défini sur false , vous n'avez donc pas besoin de les déclarer dans les fichiers TEST_MAPPING .

Pour plus d'informations sur le fonctionnement des propriétés auto_gen_config et test_suites , consultez la section Paramètres de la documentation Workflow de développement de tests .

Propriétés notables du test Rust

Les modules rust_test héritent des propriétés des modules rust_binary comme décrit sur la page Modules binaires .

Les propriétés définies dans le tableau ci-dessous s'ajoutent aux propriétés communes importantes qui s'appliquent à tous les modules. Ceux-ci sont soit particulièrement importants pour les modules de test Rust, soit présentent un comportement unique spécifique au type de module rust_test .

• test_harness : utilisation avancée, la valeur par défaut est true.

Définissez ceci sur false si votre rust_test implémente son propre harnais de test et que vous n'avez pas besoin d'utiliser le harnais de test Rust intégré (en d'autres termes, définir ceci sur false ne transmettra pas l'indicateur --test à rustc).

Évitez la duplication entre rust_library et rust_test

Lorsque vous utilisez des tests Rust en ligne via des modules imbriqués, vous vous retrouvez avec une duplication dans votre fichier Android.bp . Le problème est que vous devez lister les dépendances deux fois, une fois pour rust_library et une fois pour rust_test :

rust_library {
    name: "libfoo",
    srcs: ["src/lib.rs"],
    rustlibs: [
        "libx",
        "liby",
        "libz",
    ],
}

rust_test {
    name: "libfoo_inline_tests",
    srcs: ["src/lib.rs"],
    test_suites: ["general_tests"],
    rustlibs: [
        "libx",
        "liby",
        "libz",
    ],
}

Chaque module rust_test finira par lister les mêmes dépendances que le module rust_library correspondant. Pour assurer la cohérence entre les modules, vous pouvez lister les dépendances une seule fois dans un module rust_defaults :

rust_defaults {
    name: "libfoo_defaults",
    srcs: ["src/lib.rs"],
    rustlibs: [
        "libx",
        "liby",
        "libz",
    ],
}

rust_library {
    name: "libfoo",
    defaults: ["libfoo_defaults"],
}

rust_test {
    name: "libfoo_inline_tests",
    defaults: ["libfoo_defaults"],
    test_suites: ["general_tests"],
}

De cette façon, la bibliothèque et le module de test utiliseront toujours les mêmes dépendances.