Si vous débutez dans le développement de la plate-forme Android, vous trouverez peut-être cette étape complète. exemple d'ajout d'un tout nouveau binaire GTest (parfois appelé "fichier binaire natif") test) à partir de zéro. Cela peut être utile pour illustrer le workflow typique requis. Pour des informations supplémentaires sur le framework GTest C++, reportez-vous au guide GTest sur votre site Web pour obtenir plus d'informations.
Ce guide utilise le Test GTest Hello World. à titre d'exemple. Nous vous recommandons de lire le code afin de bien comprendre avant de continuer.
Choisir un emplacement source
En règle générale, votre équipe aura déjà établi un modèle établi de lieux de vérification dans le code, et où ajouter des tests. La plupart des équipes possèdent un seul dépôt Git. partagez-en un avec d'autres équipes, mais avez un sous-répertoire dédié qui contient le code source du composant.
En supposant que l'emplacement racine de la source de votre composant se trouve sur <component source
root>, la plupart des composants comportent des dossiers src et tests, et certains
fichiers supplémentaires tels que Android.mk (ou divisés en .bp supplémentaires)
).
Étant donné que vous ajoutez un tout nouveau test, vous devrez probablement créer le
tests à côté de votre composant src, puis remplissez-le avec du contenu.
Dans certains cas, votre équipe peut disposer d'autres structures de répertoires sous tests.
en raison de la nécessité d’empaqueter
différentes suites de tests dans des binaires individuels.
Dans ce cas, vous devez créer un sous-répertoire sous tests.
Pour illustrer, voici un aperçu de répertoire typique pour les composants avec un seul
Dossier tests:
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- src (test source)
\-- foo_test.cpp
\-- ...
Voici un schéma de répertoire type pour les composants avec plusieurs sources de test, répertoires:
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- testFoo (sub test source root)
| \-- Android.bp (sub test makefile)
| \-- src (sub test source)
| \-- test_foo.cpp
| \-- ...
\-- testBar
| \-- Android.bp
| \-- src
| \-- test_bar.cpp
| \-- ...
\-- ...
Quelle que soit la structure, vous finirez par remplir le répertoire tests ou
le sous-répertoire que vous venez de créer avec des fichiers semblables à ceux du native.
dans l'exemple de modification de gerrit. Les sections ci-dessous expliquent
plus de détails
sur chaque fichier.
Code source
Reportez-vous au test GTest Hello World. à titre d'exemple.
Le code source de cet exemple est annoté ici:
#include <gtest/gtest.h>
Fichier d'en-tête à inclure pour GTest. La dépendance du fichier
d’inclusion est automatiquement
résolu à l'aide de BUILD_NATIVE_TEST dans le fichier makefile.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
Les tests G sont écrits à l'aide de la macro TEST: le premier paramètre correspond au scénario de test.
et le second est le nom du test. Avec le nom du binaire de test, ils constituent le
dans le tableau de bord des résultats:
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
Pour en savoir plus sur l'écriture de tests avec GTest, consultez la documentation de GTest.
Fichier de configuration simple
Chaque nouveau module de test doit disposer d'un fichier de configuration le système de compilation avec les métadonnées du module, les dépendances au moment de la compilation et le packaging instructions. Dans la plupart des cas, l’option de fichier de plan basée sur Soong est suffisant. Pour en savoir plus, consultez la page Configuration de test simple.
Fichier de configuration complexe
Pour utiliser la fédération commerciale à la place, écrivez une configuration de test pour l'outil de test d'Android, Trade Fédération.
La configuration de test peut spécifier des options de configuration d'appareil spéciales et des paramètres par défaut pour fournir la classe de test.
Compiler et tester en local
Pour les cas d'utilisation les plus courants, utilisez Confirmer :
Pour les cas plus complexes nécessitant une personnalisation plus poussée, suivez le instructions d'instrumentation.