Cette page fournit des informations de base sur la création d'un module rust_test
qui utilise le banc d'essai Rust.
Écrire un test Rust de base
Pour obtenir un exemple réel de test Rust sur l'appareil et l'hôte, consultez
keystore2 Android.bp,
ou en localiser une parmi les nombreuses caisses du répertoire external/rust/crates
.
Un module rust_test
est compilé à l'aide de l'indicateur --test
de rustc, qui crée des tests à partir du code marqué par l'attribut #[test]
. Pour en savoir plus, consultez
Attributs du test de référence Rust
dans la documentation Google Cloud.
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. Même si ce n'est pas obligatoire,
si vous créez un fichier TEST_MAPPING, les tests que vous y incluez seront exécutés dans
avant de soumettre les tests et peut être appelé à l'aide de atest
.
Pour en savoir plus, consultez la documentation TEST_MAPPING. Pour l'exemple libfoo_inline_tests
, ajoutez ceci à la présoumission pour activer vos exécutions de test sur TreeHugger :
{
"presubmit": [
{
"name": "libfoo_inline_tests",
},
]
}
Notez que les modules rust_test_host
s'exécutent par défaut en présoumission, sauf si unit_tests:
est défini sur false
. Vous n'avez donc pas besoin de les déclarer dans des fichiers TEST_MAPPING
.
Pour en savoir plus sur le fonctionnement des propriétés auto_gen_config
et test_suites
,
consultez la section Paramètres
de la documentation sur le workflow de développement de tests.
Propriétés de test Rust notables
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
Propriétés communes importantes
qui s'appliquent à tous les modules. Ils sont particulièrement
importants pour Rust
modules de test ou 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 cette valeur sur "false" si votre rust_test
implémente son propre banc d'essais et que vous n'avez pas besoin d'utiliser le banc d'essais Rust intégré (en d'autres termes, si vous définissez cette valeur sur "false", l'indicateur --test
ne sera pas transmis à rustc).
Éviter la duplication entre rust_library et rust_test
Lorsque vous utilisez des tests Rust intégrés via des modules imbriqués, vous obtenez 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 répertorier 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 manière, la bibliothèque et le module de test utiliseront toujours les mêmes dépendances.