Tester le code de la plate-forme avec atest

Android Studio for Platform (ASfP) s'intègre aux modules de test atest et Soong pour vous permettre d'exécuter et de déboguer des tests de plate-forme sur votre machine hôte Linux, votre appareil connecté ou votre appareil virtuel Cuttlefish depuis l'IDE.

Prérequis

• Ouvrez un projet ASfP configuré avec votre extraction AOSP et la cible lunch.
• Pour les tests d'appareil, connectez un appareil physique ou lancez un appareil virtuel Cuttlefish exécutant une version correspondante.

Exécuter et déboguer des tests

Vous pouvez lancer des tests de plate-forme et des sessions de débogage depuis plusieurs endroits dans ASfP :

• Android.bp cibles de test : ouvrez un fichier Android.bp et cliquez sur Exécuter dans la gouttière à côté d'un module de test (*_test ou *_test_host) :
  • Run : disponible pour tous les types de modules de test Soong (android_test, java_test_host, cc_test, rust_test, python_test, sh_test et android_robolectric_test).
  • Déboguer : disponible pour les modules android_test (associés au débogueur Java à l'aide de atest --wait-for-debugger) et les modules de test C++ ou Rust (cc_test, cc_test_host, rust_test et rust_test_host, lancés sous le débogueur LLDB intégré à ASfP).
• Icônes de marge du fichier source : cliquez sur Exécuter à côté d'une classe de test ou d'une méthode @Test dans votre code source pour exécuter ou déboguer ce test spécifique.
• Menu contextuel (clic droit) : effectuez un clic droit sur un fichier de test, une classe, une méthode ou un module Android.bp, puis sélectionnez Run (Exécuter) ou Debug (Déboguer).
• Agent intégré (IA dans Android Studio) : dans la fenêtre d'outil Agent, l'agent intégré peut exécuter des cibles atest pour vérifier les modifications après la modification du code.
• Terminal intégré : ouvrez View > Tool Windows > Terminal (Affichage > Fenêtres d'outils > Terminal) pour exécuter directement les commandes atest.

Configuration et débogage des tests intelligents

Lorsque vous lancez un test depuis la gouttière ou le menu contextuel, ASfP crée et configure une configuration d'exécution Soong Test à l'aide de votre graphique de module Android.bp.

Déboguer les cibles Java et Kotlin android_test

Cliquez sur l'icône en forme de gouttière à côté d'un module android_test dans Android.bp, ou à côté d'une classe JUnit Java ou Kotlin ou d'une méthode @Test, puis sélectionnez Debug '<TestName>' (Déboguer "<NomDuTest>"). À partir d'une gouttière de fichier source, ASfP sélectionne le module android_test le plus proche dont srcs inclut le fichier et nomme la configuration <module>, <module>:<SimpleClass> ou <module>:<SimpleClass>#<method>.

ASfP exécute atest avec --wait-for-debugger, lit l'attribut package cible à partir du AndroidManifest.xml du module, attend ce processus sur l'appareil connecté et attache le débogueur Java.

Déboguer les cibles cc_test et rust_test sous LLDB

Pour déboguer un module de test C++ ou Rust (cc_test, cc_test_host, rust_test ou rust_test_host), cliquez sur l'icône de gouttière Android.bp et sélectionnez Debug '<TestName>' (Déboguer "<NomDuTest>"). ASfP lance le binaire de test compilé sous son débogueur LLDB intégré au lieu de l'exécuter via atest.

Configurer la configuration d'exécution du test Soong

Ouvrez Exécuter > Modifier les configurations et sélectionnez une configuration Soong Test pour personnaliser la façon dont les tests sont créés, déployés et lancés :

• Saisie semi-automatique des modules et navigation Android.bp : le champ Module se complète automatiquement à partir des modules de test Soong indexés dans votre projet. Cliquez sur Accéder à Android.bp à côté du champ pour accéder à la déclaration du module dans Android.bp.
• Exécuter sur : Appareil ou hôte (y compris host_supported: true) : ASfP évalue la règle du module et sa chaîne transitive defaults (host_supported, device_supported, enabled, target.android.enabled et target.host.enabled) :
  • Tests à double cible (cc_test et rust_test avec host_supported: true) : les cases d'option Appareil et Hôte sont disponibles (Appareil est sélectionné par défaut). Appareil et Hôte conservent chacun leur propre modèle de débogueur LLDB indépendant. Si vous basculez entre Exécuter sur > Appareil et Hôte, vous passez de la configuration de l'appareil distant lldb-server à celle du binaire hôte local, tout en conservant les personnalisations apportées à chaque cible.
  • Tests à cible unique : si un test C++ ou Rust n'est compilé que pour un seul environnement (par exemple, un cc_test réservé aux appareils ou un cc_test_host ou rust_test_host réservé à l'hôte), ASfP sélectionne la cible compatible et désactive la case d'option non compatible avec une info-bulle explicative : "<module> (<ruleType>) doesn't build for the host or device.".
• Tâches avant le lancement (créer un module de test natif et déployer avec atest) : Chaque configuration Soong Test inclut deux tâches Avant le lancement par défaut :
  • Build Native Test Module (Compiler le module de test natif) : compile <module>-target (pour Device) ou <module>-host (pour Host) avant de démarrer LLDB.
  • Déployer avec atest : lors du débogage sur Appareil, exécute atest <module> --collect-tests-only --disable-teardown -it -s <serial> -- --abi <abi> afin que Tradefed transmette les dépendances de test et exécute les préparateurs cibles avant que LLDB ne lance le binaire. Pointez sur le chip Déployer avec atest pour prévisualiser la commande atest exacte. Pour une itération plus rapide une fois que les dépendances sont déjà sur l'appareil, supprimez Déployer avec atest afin qu'ASfP n'envoie que le binaire de test directement. Lorsque vous sélectionnez Exécuter sur : hôte, ASfP ignore automatiquement Déployer avec atest.
• Modifier les options et le débogueur (cartes d'options LLDB) : utilisez Modifier les options pour ajouter des champs de configuration facultatifs :
  • Arguments du programme (système d'exploitation, tests C++ et Rust uniquement) : arguments supplémentaires transmis directement au binaire cc_test ou rust_test après le filtre --gtest_filter ou libtest lors du débogage.
  • Arguments atest (Test) : indicateurs supplémentaires transmis à atest lors de l'exécution du test ou lors de la préparation d'un appareil avec Déployer avec atest.
  • Débogueur (tests C++ et Rust uniquement) : s'affiche lorsque Module est une cible cc_test* ou rust_test*. Activez les fiches Options LLDB (comme Arrêter à l'entrée, Mettre en cache les symboles entre les sessions, Charger les symboles à la demande ou Avec les visualisateurs Rust pour les tests Rust), cliquez sur Rétablir les valeurs par défaut pour réinitialiser le modèle Appareil ou Hôte actif, ou ajoutez Répertoires de symboles, Commandes Init, Pré-exécution, Post-exécution ou Quitter et Lancer JSON (Paramètres DAP) depuis Modifier les options > Débogueur.

Afficher les résultats des tests

La progression de l'exécution des tests, l'état de réussite ou d'échec, les traces de la pile et les journaux de l'appareil s'affichent en temps réel dans la fenêtre d'un outil Exécuter ou Déboguer d'ASfP.

Conseils pour les tests

• Exécuter des tests ciblés : testez des méthodes individuelles à partir de la marge de l'éditeur sans exécuter une suite de tests complète.
• Utiliser les instantanés Cuttlefish : lorsque vous exécutez des tests d'appareil sur des appareils virtuels Cuttlefish, utilisez des instantanés pour restaurer un état propre de l'appareil entre les exécutions.
• Inspecter les journaux de compilation Soong : si un test ne parvient pas à être compilé avant l'exécution, consultez la fenêtre d'outil Soong pour obtenir des diagnostics du compilateur.