Ciblage d'un exemple d'application

Cette catégorie de test d'instrumentation n'est pas si différente de celles qui ciblent 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à quelques connaissances sur le workflow de l'arborescence des sources de la plate-forme. 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 un package cible défini dans son propre package d'application de test. Si vous n'êtes pas familier avec le concept, s'il vous plaît lire la mise en place de tester la plate - forme .

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

  • frameworks/base/packages/Shell/tests

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

Décider d'un emplacement source

Parce que le test d'instrumentation ciblera une application, la convention est de placer le code source de test dans un des tests répertoire sous la racine de votre répertoire source composant dans l' arborescence source de la plate - forme.

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

Fichier manifeste

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

Avant d' aller plus loin, il est fortement recommandé de passer par l' App Manifest Vue d' ensemble d' abord.

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">

Le package attribut est le nom du package d'application: il est l'identifiant unique que l'utilisation du cadre d'application Android 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.

Comme il est un ensemble d'applications de test, indépendamment du dossier de demande en cours de test, doit être utilisé un autre nom de package: une convention commune est d'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 cela. 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 votre nom de 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 séparé, ce qui 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"

Ceci définit le paquet cible de l'instrumentation à com.android.shell . Lorsque l'instrumentation est invoquée par am instrument commande, le redémarrage du cadre com.android.shell processus et injecte du code d'instrumentation dans le processus d'exécution des tests. Cela signifie également que le code de test aura accès à toutes les instances de classe s'exécutant dans l'application testée et peut être capable de 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 les tests plus complexes, vous devez également é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.

Dernière version du fichier de configuration pour le changement échantillon de Gerrit peut être consulté à: cadres / 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électives 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 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 Trade Federation à utiliser pour exécuter le test et transmet le package sur le périphérique à exécuter et le framework de testeur qui est JUnit dans ce cas.

Regardez ici pour plus d' informations sur le module de test Configs

Fonctionnalités de JUnit4

En utilisant android-support-test de bibliothèque comme lanceur de test permet adoptation de nouvelles classes d'essai de style junit4, et le changement de l' échantillon Gerrit contient une utilisation très basique de ses caractéristiques.

Dernier code source pour le changement échantillon de Gerrit est accessible à: cadres / 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 obligés 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.

La @SmallTest annotation spécifié une taille de test pour la classe de test complet: toutes les méthodes d'essai ajoutés dans cette classe de test hériteront de cette taille test de l' annotation. pré installation de classe de test, déchirure après essai vers le bas, et la déchirure de la classe de test post bas: similaire à setUp et tearDown méthodes junit4. Test de l' annotation est utilisé pour annoter le test réel.

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

La @Before annotation est utilisé sur les méthodes par junit4 pour effectuer la configuration de test pré. Bien que non utilisé dans cet exemple, il y a aussi @After pour désassemblage post test. De même, les @BeforeClass et @AfterClass annotations sont peuvent être utilisés sur les méthodes par junit4 pour effectuer l' installation avant d' exécuter tous les tests dans une classe de test, et après désassemblage. Notez que les méthodes de configuration et de suppression de la portée de la classe doivent être statiques.

En ce qui concerne les méthodes d'essai, contrairement à la version antérieure de JUnit, ils ne ont plus besoin de lancer le nom de la méthode avec test , au contraire, chacun d'eux doit être annotés 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();

Parce que les essais n junit4 plus besoin d' une classe de base commune, il est plus nécessaire d'obtenir Context instances par getContext() ou getTargetContext() via des méthodes de classe de base; à la place, le nouveau coureur de test les gère via InstrumentationRegistry où la configuration contextuelle et l' environnement créé par le cadre d'instrumentation est stocké. Grâce à cette classe, vous pouvez également appeler :

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

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 .