Si vous débutez dans le développement de la plate-forme Android, cet exemple complet d'ajout d'un tout nouveau binaire GTest (également appelé test "natif") à partir de zéro peut vous être utile pour illustrer le workflow typique impliqué. Pour en savoir plus sur le framework GTest pour C++, consultez le site du projet GTest pour obtenir de la documentation supplémentaire.
Ce guide utilise l'exemple Hello World GTest. Nous vous recommandons de lire le code pour en avoir une idée générale avant de continuer.
Choisir un emplacement source
En général, votre équipe aura déjà établi un modèle de lieux à vérifier dans le code et de lieux où ajouter des tests. La plupart des équipes possèdent un seul dépôt Git ou en partagent un avec d'autres équipes, mais disposent d'un sous-répertoire dédié contenant le code source des composants.
En supposant que l'emplacement racine de la source de votre composant se trouve à <component source
root>, la plupart des composants ont des dossiers src et tests en dessous, ainsi que des fichiers supplémentaires tels que Android.mk (ou divisés en fichiers .bp supplémentaires).
Comme vous ajoutez un tout nouveau test, vous devrez probablement créer le répertoire tests à côté de votre composant src et le remplir de contenu.
Dans certains cas, votre équipe peut avoir d'autres structures de répertoire sous tests en raison de la nécessité d'empaqueter différentes suites de tests dans des binaires individuels.
Dans ce cas, vous devrez créer un sous-répertoire sous tests.
Pour illustrer cela, voici un aperçu typique de la structure de répertoire 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 aperçu typique de la structure de répertoire pour les composants avec plusieurs répertoires de sources de test :
\
<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 nouvellement créé avec des fichiers semblables à ceux du répertoire native dans l'exemple de modification Gerrit. Les sections ci-dessous décrivent chaque fichier plus en détail.
Code source
Pour obtenir un exemple, consultez Hello World GTest.
Le code source de cet exemple est annoté ici :
#include <gtest/gtest.h>
Fichier d'en-tête inclus pour GTest. La dépendance du fichier include est automatiquement résolue à l'aide de BUILD_NATIVE_TEST dans le fichier makefile.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
Les GTests sont écrits à l'aide de la macro TEST : le premier paramètre est le nom du cas de test et le second est le nom du test. Avec le nom du binaire de test, ils forment la hiérarchie suivante 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 GTest.
Fichier de configuration simple
Chaque nouveau module de test doit disposer d'un fichier de configuration pour diriger le système de compilation avec les métadonnées du module, les dépendances de compilation et les instructions d'empaquetage. Dans la plupart des cas, l'option de fichier Blueprint basé sur Soong est suffisante. Pour en savoir plus, consultez Configuration simple des tests.
Fichier de configuration complexe
Pour utiliser Trade Federation, écrivez un fichier de configuration de test pour le harnais de test d'Android, Trade Federation.
La configuration de test peut spécifier des options spéciales de configuration de l'appareil et des arguments par défaut à fournir à la classe de test.
Compiler et tester en local
Pour les cas d'utilisation les plus courants, utilisez Atest.
Pour les cas plus complexes nécessitant une personnalisation plus poussée, suivez les instructions d'instrumentation.