Google s'est engagé à promouvoir l'équité raciale pour les communautés noires. Regarde comment.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Ajout d'un nouvel exemple de test natif

Si vous débutez dans le développement de plates-formes Android, vous trouverez peut-être cet exemple complet d'ajout d'un tout nouveau test natif à partir de zéro utile pour illustrer le flux de travail typique impliqué. De plus, si vous ne connaissez pas non plus le framework gtest pour C ++, veuillez consulter le site du projet gtest pour obtenir de la documentation supplémentaire.

Ce guide utilise le test suivant pour servir d'exemple:

Test natif de Hello World

Il est recommandé de parcourir d'abord le code pour avoir une impression approximative avant de continuer.

Décider d'un emplacement source

En règle générale, votre équipe dispose déjà d'un modèle bien établi d'emplacements pour enregistrer le code et d'emplacements pour ajouter des tests. La plupart des équipes possèdent un seul référentiel git, ou en partagent un avec d'autres équipes mais ont un sous-répertoire dédié qui contient le code source du composant.

En supposant que l'emplacement racine de votre source de composant se trouve à <component source root> , la plupart des composants ont des dossiers src et tests sous lui, ainsi que des fichiers supplémentaires tels Android.mk (ou .bp fichiers .bp supplémentaires).

Puisque vous ajoutez un tout nouveau test, vous devrez probablement créer le répertoire des tests côté de votre composant src et le remplir avec du contenu.

Dans certains cas, votre équipe peut avoir d'autres structures de répertoires en cours de tests raison de la nécessité de regrouper différentes suites de tests dans des binaires individuels. Et dans ce cas, vous devrez créer un nouveau sous-répertoire sous tests .

Pour illustrer, voici un aperçu de répertoire typique pour les composants avec un seul dossier de 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
          \-- ...
 

et voici un aperçu de répertoire typique pour les composants avec plusieurs répertoires source 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 de tests ou le sous-répertoire nouvellement créé avec des fichiers similaires à ce qui se trouve dans native répertoire native dans l'exemple de changement de gerrit. Les sections ci-dessous expliquent plus en détail chaque fichier.

Code source

Voir le test natif Hello World pour un exemple.

Le code source annoté est répertorié ci-dessous:

 #include <gtest/gtest.h>
 

Le fichier d'en-tête inclut pour gtest. Notez que la dépendance de fichier d'inclusion est automatiquement résolue en utilisant BUILD_NATIVE_TEST dans le 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 scénario de test et le second est le nom du test; avec le nom binaire du test, ils forment la hiérarchie ci-dessous lorsqu'ils sont visualisés 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 plus d'informations sur l'écriture de tests avec gtest, consultez sa documentation:

  • https://github.com/google/googletest/blob/master/googletest/docs/Primer.md

Fichier de configuration 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. Dans la plupart des cas, l'option de fichier Blueprint basée sur Soong est suffisante. Voir Configuration de test simple pour plus de détails.

Fichier de configuration complexe

Pour utiliser Trade Federation à la place, écrivez un fichier de configuration de test pour le faisceau de test d'Android, Trade Federation .

La configuration de test peut spécifier des options de configuration de périphérique spéciales et des arguments par défaut pour fournir la classe de test.

Construire et tester localement

Pour les cas d'utilisation les plus courants, utilisez Atest .

Pour les cas plus complexes nécessitant une personnalisation plus lourde, suivez les instructions d'instrumentation .