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

Cibler un exemple d'application

Cette catégorie de test d'instrumentation n'est pas si différente de celles ciblant les applications Android classiques. Il convient de noter que l'application de test qui comprenait l'instrumentation doit être signée avec le même certificat que l'application qu'elle cible.

Notez que ce guide suppose que vous avez déjà des connaissances sur le flux de travail de l'arborescence des sources de la plateforme. Sinon, veuillez vous référer à https://source.android.com/source/requirements. L'exemple couvert ici est l'écriture d'un nouveau test d'instrumentation avec le package cible défini dans son propre package d'application de test. Si vous n'êtes pas familier avec le concept, veuillez lire l' introduction des tests de plate - forme .

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

  • frameworks / base / packages / Shell / tests

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

Décider d'un emplacement source

Étant donné que le test d'instrumentation ciblera une application, la convention consiste à placer le code source du test dans un répertoire de tests sous la racine du répertoire source de votre composant dans l'arborescence des sources de la plateforme.

Voir plus de discussions sur l'emplacement source dans l' exemple de bout en bout pour les tests d'auto-instrumentation .

Fichier manifeste

Tout comme une application classique, chaque module de test d'instrumentation a besoin d'un fichier manifeste. Si vous nommez le fichier AndroidManifest.xml et que vous le fournissez à côté d' Android.mk pour votre module de test, il sera automatiquement inclus par le makefile principal BUILD_PACKAGE .

Avant de continuer, il est fortement recommandé de consulter d'abord la vue d'ensemble du manifeste d'application .

Cela donne un aperçu des composants de base d'un fichier manifeste et de leurs fonctionnalités.

La dernière version du fichier manifeste pour l'exemple de modification de gerrit est accessible à l'adresse: https://android.googlesource.com/platform/frameworks/base/+/master/packages/Shell/tests/AndroidManifest.xml

Un instantané est inclus ici pour plus de commodité:

 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

    <application>
        <uses-library android:name="android.test.runner" />

        <activity
            android:name="com.android.shell.ActionSendMultipleConsumerActivity"
            android:label="ActionSendMultipleConsumer"
            android:theme="@android:style/Theme.NoDisplay"
            android:noHistory="true"
            android:excludeFromRecents="true">
            <intent-filter>
                <action android:name="android.intent.action.SEND_MULTIPLE" />
                <category android:name="android.intent.category.DEFAULT" />
                <data android:mimeType="*/*" />
            </intent-filter>
        </activity>
    </application>

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
        android:targetPackage="com.android.shell"
        android:label="Tests for Shell" />

</manifest>
 

Quelques remarques sélectionnées sur le fichier manifeste:

 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">
 

L'attribut package est le nom du package d'application: il s'agit de l'identifiant unique que le framework d'application Android utilise pour identifier une application (ou dans ce contexte: votre application de test). Chaque utilisateur du système ne peut installer qu'une seule application avec ce nom de package.

Puisqu'il s'agit d'un package d'application de test, indépendant du package d'application testé, un nom de package différent doit être utilisé: une convention courante consiste à ajouter un suffixe .test .

De plus, ce package attribut est le même que ce que ComponentName#getPackageName() retourne, et aussi le même que vous utilisez pour interagir avec différentes pm commandes sous via adb shell .

Veuillez également noter que bien que le nom du package soit généralement dans le même style qu'un nom de package Java, il a en fait très peu de choses à voir avec lui. En d'autres termes, votre package d'application (ou de test) peut contenir des classes avec n'importe quel nom de package, mais d'un autre côté, vous pouvez opter pour la simplicité et avoir le nom de votre package Java de niveau supérieur dans votre application ou test identique au nom du package d'application.

 <uses-library android:name="android.test.runner" />
 

Ceci est requis pour tous les tests d'instrumentation car les classes associées sont empaquetées dans un fichier de bibliothèque jar de framework distinct, et nécessite donc des entrées de chemin de classe supplémentaires lorsque le package de test est appelé par le framework d'application.

 android:targetPackage="com.android.shell"
 

Cela définit le package cible de l'instrumentation sur com.android.shell.tests . Lorsque l'instrumentation est appelée via la commande am instrument , le framework redémarre le processus com.android.shell.tests et injecte le code d'instrumentation dans le processus pour l'exécution du test. Cela signifie également que le code de test aura accès à toutes les instances de classe exécutées dans l'application testée et pourra peut-être manipuler l'état en fonction des hooks de test exposés.

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 des tests plus complexes, vous devez également écrire 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.

La dernière version du fichier de configuration pour l'exemple de modification de gerrit est accessible à l'adresse: frameworks / base / packages / Shell / tests / AndroidTest.xml

Un instantané est inclus ici pour plus de commodité:

 <configuration description="Runs Tests for Shell.">
    <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
        <option name="test-file-name" value="ShellTests.apk" />
    </target_preparer>

    <option name="test-suite-tag" value="apct" />
    <option name="test-tag" value="ShellTests" />
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="com.android.shell.tests" />
        <option name="runner" value="android.support.test.runner.AndroidJUnitRunner" />
    </test>
</configuration>
 

Quelques remarques sélectionnées sur le fichier de configuration de test:

 <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
  <option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>
 

Cela indique à Trade Federation d'installer ShellTests.apk sur le périphérique cible à l'aide d'un target_preparer spécifié. Il existe de nombreux préparateurs de cibles disponibles pour les développeurs dans Trade Federation et ceux-ci peuvent être utilisés pour s'assurer que l'appareil est correctement configuré avant l'exécution du test.

 <test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="com.android.shell.tests"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>
 

Cela spécifie la classe de test de la fédération commerciale à utiliser pour exécuter le test et passe dans le package sur le périphérique à exécuter et le framework de test runner qui est JUnit dans ce cas.

Regardez ici pour plus d'informations sur les configurations de module de test

Fonctionnalités de JUnit4

L'utilisation de la bibliothèque android-support-test comme testeur permet l'adoption de nouvelles classes de test de style JUnit4, et l'exemple de changement de gerrit contient une utilisation très basique de ses fonctionnalités.

Le dernier code source de l'exemple de modification de gerrit est accessible à l'adresse: frameworks / base / packages / Shell / tests / src / com / android / shell / BugreportReceiverTest.java

Bien que les modèles de test soient généralement spécifiques aux équipes de composants, il existe des modèles d'utilisation généralement utiles.

 @SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {
 

Une différence significative dans JUnit4 est que les tests ne sont plus tenus d'hériter d'une classe de test de base commune; à la place, vous écrivez des tests dans des classes Java simples et utilisez des annotations pour indiquer certaines configurations et contraintes de test. Dans cet exemple, nous indiquons que cette classe doit être exécutée en tant que test Android JUnit4.

L'annotation @SmallTest spécifiait une taille de test pour toute la classe de test: toutes les méthodes de test ajoutées à cette classe de test héritent de cette annotation de taille de test. configuration de la classe pré-test, démontage post-test et setUp classe post-test: similaire aux méthodes setUp et tearDown dans JUnit4. Test annotation de Test est utilisée pour annoter le test réel.

     @Before
    public void setup() {
    ...
    @Test
    public void testGetProvider_shouldCacheProvider() {
    ...
 

L'annotation @Before est utilisée sur les méthodes de JUnit4 pour effectuer la configuration du pré-test. Bien que non utilisé dans cet exemple, il existe également @After pour le démontage post-test. De même, les annotations @BeforeClass et @AfterClass peuvent être utilisées sur les méthodes par JUnit4 pour effectuer la configuration avant d'exécuter tous les tests dans une classe de test, puis démonter. Notez que les méthodes de configuration et de suppression de l'étendue de la classe doivent être statiques.

Quant aux méthodes de test, contrairement à la version précédente de JUnit, elles n'ont plus besoin de démarrer le nom de la méthode avec test , à la place, chacune d'elles doit être annotée avec @Test . Comme d'habitude, les méthodes de test doivent être publiques, ne déclarer aucune valeur de retour, ne prendre aucun paramètre et peuvent lever des exceptions.

         Context context = InstrumentationRegistry.getTargetContext();
 

Étant donné que les tests JUnit4 ne nécessitent plus une classe de base commune, il n'est plus nécessaire d'obtenir des instances de Context via getContext() ou getTargetContext() via des méthodes de classe de base; au lieu de cela, le nouveau testeur les gère via InstrumentationRegistry où la configuration contextuelle et environnementale créée par l'infrastructure d'instrumentation est stockée. Grâce à ce cours, vous pouvez également appeler:

  • getInstrumentation() : l'instance de la classe Instrumentation
  • getArguments() : les arguments de ligne de commande passés à un am instrument via -e <key> <value>

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 .