Ajout d'un nouvel exemple de test natif

Si vous débutez dans le développement de plate-forme Android, vous trouverez peut-être cet exemple complet d'ajout d'un tout nouveau test natif à partir de zéro utile pour démontrer le flux de travail typique impliqué. De plus, si vous êtes également familier avec le cadre gtest C ++, s'il vous plaît examiner le site du projet gtest pour des documents supplémentaires.

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

Bonjour tout le monde test natif

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

Décider d'un emplacement source

En règle générale, votre équipe aura déjà un modèle établi d'endroits pour enregistrer le code et d'endroits 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 disposent d'un sous-répertoire dédié contenant le code source du composant.

En supposant que l'emplacement racine pour votre source composant est à <component source root> , la plupart des composants ont src et des tests sous-dossiers et des fichiers supplémentaires tels que Android.mk (ou morcelée en d' autres .bp fichiers).

Puisque vous ajoutez une nouvelle marque test, vous aurez probablement besoin de créer des tests répertoire à côté de votre composant src , et le remplir avec le contenu.

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

Pour illustrer, voici un aperçu du répertoire typique pour les composants avec un seul des tests dossier:

\
 <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 de 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 peuplant les tests de répertoire ou le sous - répertoire nouvellement créé avec des fichiers similaires à ce qui est dans native répertoire dans le changement échantillon de Gerrit. Les sections ci-dessous expliqueront plus en détail chaque fichier.

Code source

Voir le test Bonjour tout le monde indigène pour un exemple.

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

#include <gtest/gtest.h>

Fichier d'en-tête inclus pour gtest. Notez que la dépendance incluent des fichiers est automatiquement résolu en utilisant BUILD_NATIVE_TEST dans le makefile

#include <stdio.h>

TEST(HelloWorldTest, PrintHelloWorld) {
    printf("Hello, World!");
}

gtests sont écrits en utilisant TEST macro: le premier paramètre est le nom de cas de test, et le second est le nom de test; avec le nom du binaire de 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 la Fédération du commerce à la place, écrire un fichier de configuration de test pour harnais de test d'Android, la Fédération du Commerce .

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 la plupart des cas d'utilisation commune, emploi Atest .

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