Cartographie des tests

Il s'agit d'une brève introduction à la mise en correspondance des tests et d'une explication de la façon d'obtenir a commencé à configurer des tests dans le projet Android Open Source (AOSP).

À propos du mappage test

Le mappage de test est une approche basée sur Gerrit qui permet aux développeurs de créer des éléments et les règles de test postsubmit directement dans l'arborescence source Android, et laissez les décisions des branches et des appareils à tester sur l’infrastructure de test. Les définitions de mappage de test sont des fichiers JSON nommés TEST_MAPPING que vous pouvez dans n'importe quel répertoire source.

Atest peut utiliser les fichiers TEST_MAPPING pour exécuter des tests avant l'envoi dans les répertoires associés. Avec le mappage de test, vous pouvez ajouter le même ensemble de tests vérifications avant envoi avec un minimum de modifications dans l'arborescence source Android.

Voici quelques exemples :

• Ajoutez des tests de pré-envoi à TEST_MAPPING pour services.core

• Ajoutez des tests de pré-envoi à TEST_MAPPING pour tools/dexter en utilisant des importations

Le mappage des tests s'appuie sur le harnais de test de la Trade Federation (TF) pour l'exécution des tests et la création de rapports sur les résultats.

Définir des groupes de test

Testez les tests de groupes de mappage avec un groupe de test. Le nom d'un groupe de test peut être n'importe quelle chaîne. Par exemple, presubmit peut être le nom d'un groupe de tests à exécuter lors de la validation des modifications. Les tests postsubmit peuvent être utilisés pour valider les builds après la fusion des modifications.

Règles du script de compilation du package

Pour que l'atelier de test de la Fédération commerciale pour exécuter des modules de test pour une compilation donnée, ils doivent avoir un test_suites défini pour Soong ou LOCAL_COMPATIBILITY_SUITE défini pour utiliser l'une de ces deux suites:

• general-tests est destiné aux tests qui ne dépendent pas des fonctionnalités spécifiques à l'appareil (comme le matériel spécifique au fournisseur que la plupart des appareils ne possèdent pas). La plupart des tests doivent se trouver dans la suite general-tests, même s'ils sont spécifiques à une ABI, à une taille d'octet ou à des fonctionnalités matérielles telles que HWASan (il existe une cible test_suites distincte pour chaque ABI), et même s'ils doivent s'exécuter sur un appareil.
• device-tests est destiné aux tests qui dépendent de fonctionnalités spécifiques à l'appareil. Ces tests se trouvent généralement sous vendor/. Spécifique à l'appareil ne fait référence qu'aux fonctionnalités propres à un appareil. Cela s'applique donc aux tests JUnit ainsi qu'aux tests GTest (qui doivent généralement être marqués comme general-tests, même s'ils sont spécifiques à l'ABI).

Exemples :

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

Configurer des tests à exécuter dans une suite de tests

Pour qu'un test s'exécute dans une suite de tests, il doit:

• Ne doit pas avoir de fournisseur de compilation.
• Le nettoyage doit être effectué une fois le test terminé, par exemple en supprimant les fichiers temporaires générés pendant le test.
• Vous devez rétablir les valeurs par défaut ou d'origine des paramètres système.

• Ne pas supposer qu'un appareil est dans un état donné, par exemple prêt à être root. La plupart des tests ne nécessitent pas de droits racine pour s'exécuter. Si un test doit nécessiter racine, il doit spécifier cela avec RootTargetPreparer dans son AndroidTest.xml comme dans l'exemple suivant:

  <target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
  

Créer des fichiers de mappage de test

Pour le répertoire nécessitant une couverture de test, ajoutez un fichier JSON TEST_MAPPING semblable à l'exemple. Ces règles garantissent que les tests s'exécutent dans les vérifications préalables à l'envoi lorsque des fichiers sont modifiés dans ce répertoire ou dans l'un de ses sous-répertoires.

Suivre un exemple

Voici un exemple de fichier TEST_MAPPING (au format JSON, mais avec des commentaires acceptés) :

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsDeqpTestCases",
      "options": [
        {
          // Use regex in include-filter which is supported in AndroidJUnitTest
          "include-filter": "dEQP-EGL.functional.color_clears.*"
        }
      ]
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Définir les attributs

Dans l'exemple, presubmit et postsubmit sont les noms de chaque groupe de test. Pour en savoir plus sur les groupes de test, consultez la section Définir des groupes de test.

Vous pouvez définir le nom du module de test ou du nom du test d'intégration de la Trade Federation (chemin d'accès aux ressources vers le fichier XML de test, par exemple, uiautomator/uiautomator-demo) dans la valeur de l'attribut name. Notez que le champ name ne peut pas Utilisez la classe name ou la méthode de test name. Pour affiner les tests à exécuter, utilisez des options telles que include-filter. Consultez l'exemple d'utilisation de include-filter.

Le paramètre host d'un test indique s'il s'agit d'un test sans appareil exécuté sur l'hôte ou non. La valeur par défaut est false, ce qui signifie que le test nécessite un appareil pour fonctionner. Les types de tests acceptés sont les suivants : HostGTest pour Binaires GTest et HostTest pour JUnit tests.

L'attribut file_patterns vous permet de définir une liste de chaînes d'expression régulière pour faire correspondre le chemin d'accès relatif de n'importe quel fichier de code source (par rapport au répertoire contenant le fichier TEST_MAPPING). Dans l'exemple, le test CtsWindowManagerDeviceTestCases s'exécute en présoumission uniquement lorsqu'un fichier Java commence par Window ou Activity, qui se trouve dans le même répertoire que le fichier TEST_MAPPING ou l'un de ses sous-répertoires. Les barres obliques inverses (\) doivent être échappées, car elles se trouvent dans un fichier JSON.

L'attribut imports vous permet d'inclure des tests dans d'autres fichiers TEST_MAPPING sans copier le contenu. Les fichiers TEST_MAPPING dans le dossier parent les répertoires du chemin importé sont également inclus. Le mappage de test permet les importations imbriquées. Cela signifie que deux fichiers TEST_MAPPING peuvent s'importer mutuellement, et que le mappage de test peut fusionner les tests inclus.

L'attribut options contient des options de ligne de commande Tradefed supplémentaires.

Pour obtenir la liste complète des options disponibles pour un test donné, exécutez la commande suivante:

tradefed.sh run commandAndExit [test_module] --help

Consultez Gestion des options dans Tradefed pour en savoir plus sur le fonctionnement des options.

Exécuter des tests avec Atest

Pour exécuter les règles de test présoumission localement :

1. Accédez au répertoire contenant le fichier TEST_MAPPING.

2. Exécutez la commande suivante :

   atest
   

Tous les tests de présoumission configurés dans les fichiers TEST_MAPPING du répertoire actuel et de ses répertoires parents sont exécutés. Atest localise et exécute deux tests pour le pré-envoi (A et B).

Il s'agit du moyen le plus simple d'exécuter des tests de présoumission dans les fichiers TEST_MAPPING du répertoire de travail actuel (RDT) et des répertoires parents. Atest recherche et utilise le fichier TEST_MAPPING dans le répertoire de travail courant et tous ses répertoires parents.

Structurer le code source

Cet exemple montre comment configurer des fichiers TEST_MAPPING dans le arborescence source:

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

Contenu de src/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

Contenu de src/project_1/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

Contenu de src/project_2/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

Spécifier les répertoires cibles

Vous pouvez spécifier un répertoire cible pour exécuter des tests dans les fichiers TEST_MAPPING de ce répertoire. La commande suivante exécute deux tests (A, B) :

atest --test-mapping src/project_1

Exécuter les règles de test post-soumission

Vous pouvez également utiliser cette commande pour exécuter les règles de test post-soumission définies dans TEST_MAPPING dans src_path (par défaut, CWD) et ses répertoires parents :

atest [--test-mapping] [src_path]:postsubmit

Exécuter uniquement les tests qui ne nécessitent aucun appareil

Vous pouvez utiliser l'option --host pour Atest afin d'exécuter uniquement les tests configurés sur l'hôte qui n'exige aucun appareil. Sans cette option, Atest exécute les deux tests, ceux qui nécessitent un appareil et ceux qui s'exécutent sur un hôte qui n'en nécessite pas. Les tests sont exécutés dans deux suites distinctes:

atest [--test-mapping] --host

Identifier les groupes de test

Vous pouvez spécifier des groupes de test dans la commande Atest. La commande suivante exécute tous les tests postsubmit liés aux fichiers du répertoire src/project_1, qui ne contient qu'un seul test (C).

Vous pouvez également utiliser :all pour exécuter tous les tests, quel que soit le groupe. Les éléments suivants : exécute quatre tests (A, B, C, X):

atest --test-mapping src/project_1:all

Inclure les sous-répertoires

Par défaut, les tests dans TEST_MAPPING avec Atest n'exécutent que le pré-envoi configurés dans le fichier TEST_MAPPING dans CWD (ou un répertoire donné) et ses répertoires parents. Si vous souhaitez exécuter des tests dans tous les fichiers TEST_MAPPING des sous-répertoires, utilisez l'option --include-subdir pour forcer Atest à inclure également ces tests.

atest --include-subdir

Sans l'option --include-subdir, Atest n'exécute que le test A. Avec l'option --include-subdir, Atest exécute deux tests (A, B).

Commentaires au niveau de la ligne acceptés

Vous pouvez ajouter un commentaire de format // au niveau de la ligne pour étoffer le fichier TEST_MAPPING avec une description du paramètre qui suit. ATest et Trade Federation prétraitent TEST_MAPPING en un format JSON valide sans commentaires. Pour que le fichier JSON reste propre, seul le commentaire de format // au niveau de la ligne est accepté.

Exemple :

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}