Exemple de ciblage d'une application

Cette catégorie de tests d'instrumentation n'est pas très différente des critères de ciblage les applications Android standards. Notez que l'application de test incluant l'instrumentation doit être signée avec le même certificat que l'application qu'il cible.

Dans ce guide, nous partons du principe que vous avez déjà quelques connaissances dans les domaines suivants : et le workflow d'arborescence source de la plate-forme. Si ce n'est pas le cas, consultez les Conditions requises. L'exemple présenté ici consiste à écrire un nouveau test d'instrumentation avec dans son propre package d'application de test. Si vous ne connaissez pas les consultez l'introduction aux tests de plates-formes.

Ce guide utilise le test suivant comme exemple:

  • frameworks/base/packages/interface système/tests

Nous vous recommandons de commencer par parcourir le code pour obtenir une impression approximative avant de continuer.

Choisir un emplacement source

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

Consultez d'autres discussions sur l'emplacement source dans l'exemple de bout en bout pour d'auto-instrumentation.

Fichier manifeste

Tout comme les applications standards, chaque module de test d'instrumentation nécessite fichier manifeste. Si vous nommez le fichier AndroidManifest.xml et que vous le fournissez à Android.mk pour votre module de test, il sera inclus automatiquement par Makefile de base BUILD_PACKAGE.

Avant de continuer, nous vous recommandons vivement de consulter les Présentation du fichier manifeste d'application en premier.

Il donne un aperçu des composants de base d'un fichier manifeste et de leurs de Google Cloud.

La dernière version du fichier manifeste pour l'exemple de modification Gerrit est accessible à l'adresse: https://android.googlesource.com/platform/frameworks/base/+/main/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 concernant le fichier manifeste:

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

L'attribut package correspond au nom du package de l'application: il s'agit de l'attribut que le framework d'application Android utilise pour identifier 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 test, indépendant de l'application package testé, un nom de package différent doit être utilisé: une convention courante consiste à ajouter un suffixe .test.

De plus, cet attribut package est identique à ce que vous ComponentName#getPackageName() ainsi que pour interagir avec différents sous-ensembles pm via adb shell.

Notez également que, même si le nom du package est généralement de la même manière, en tant que nom de package Java, il a en fait très peu de choses à faire avec. Dans d'autres votre package d'application (ou de test) peut contenir des classes avec n'importe quel package de noms de domaine. D'un autre côté, vous pouvez opter pour la simplicité et faire en sorte du package Java du niveau de service dans votre application ou test identique à l'application nom du package.

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

Cela est obligatoire pour tous les tests d'instrumentation, car les classes associées sont empaquetés dans un fichier de bibliothèque JAR de framework distinct, ce qui nécessite Entrées classpath 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. Lorsque l'instrumentation est appelée via la commande am instrument, le framework redémarre le processus com.android.shell et injecte le code d'instrumentation dans le processus d'exécution du test. Cela signifie également que le code de test l'accès à toutes les instances de classe s'exécutant dans l'application testée et peut de pouvoir manipuler l'état dépend des hooks de test exposés.

Fichier de configuration simple

Chaque nouveau module de test doit disposer d'un fichier de configuration le système de compilation avec les métadonnées du module, les dépendances au moment de la compilation et le packaging instructions. Dans la plupart des cas, l’option de fichier de plan basée sur Soong est suffisant. Pour en savoir plus, consultez la page Configuration de test simple.

Fichier de configuration complexe

Pour les tests plus complexes, vous devez également écrire une configuration de test pour l'outil de test d'Android, Trade Fédération.

La configuration de test peut spécifier des options de configuration d'appareil spéciales et des paramètres par défaut pour fournir la classe de test.

La dernière version du fichier de configuration pour l'exemple de modification 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>

Remarques importantes concernant le fichier de configuration du test:

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

Cela indique à la fédération commerciale d'installer ShellTests.apk sur la cible appareil à l'aide d'un target_preparer spécifié. Il existe de nombreux préparateurs cibles à la disposition des développeurs de la Fédération commerciale 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 de commerce à utiliser pour exécuter le test et transmet le package sur l'appareil à exécuter et le lanceur de test qui est JUnit dans ce cas.

Cliquez ici pour en savoir plus sur les configurations de modules de test.

Fonctionnalités de JUnit4

L'utilisation de la bibliothèque android-support-test en tant qu'exécuteur de test permet d'adopter de nouvelles à des classes de test de style JUnit4, et l'exemple de modification de gerrit contient des éléments de ses fonctionnalités.

Le code source le plus récent pour l'exemple de modification Gerrit est disponible à l'adresse suivante: 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 nécessaires pour hériter d'une classe de test de base commune ; vous écrivez les tests en langage Java et utilisent des annotations pour indiquer certaines contraintes et configuration de test. Dans Dans cet exemple, nous indiquons que cette classe doit être exécutée en tant que Test JUnit4.

L'annotation @SmallTest a spécifié une taille de test pour l'ensemble de la classe de test: tous Les méthodes de test ajoutées à cette classe de test héritent de cette annotation de taille de test. Suppression avant la configuration du cours, suppression post-test et suppression après test: semblables aux méthodes setUp et tearDown dans JUnit4. L'annotation Test permet d'annoter le test réel.

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

L'annotation @Before est utilisée sur les méthodes par JUnit4 pour effectuer une configuration avant le test. Bien qu'il ne soit pas utilisé dans cet exemple, il existe également @After pour la suppression post-test. De même, les annotations @BeforeClass et @AfterClass peuvent être utilisées sur par JUnit4 pour effectuer la configuration avant d'exécuter tous les tests dans une classe de test, puis de le supprimer. Notez que les méthodes de configuration et de suppression à l'échelle de la classe doit être statique.

En ce qui concerne les méthodes de test, contrairement à la version précédente de JUnit, elles n'ont plus besoin Pour commencer le nom de la méthode par test, chacune d'entre elles doit être annotée avec @Test. Comme d'habitude, les méthodes de test doivent être publiques, ne déclarer aucune valeur renvoyée, n'acceptent aucun paramètre et peuvent générer des exceptions.

        Context context = InstrumentationRegistry.getTargetContext();

Comme les tests JUnit4 ne nécessitent plus de classe de base commune, il n'est plus nécessaire nécessaire pour obtenir des instances Context via getContext() ou getTargetContext() via les méthodes de la classe de base ; à la place, le nouveau lanceur de test les gère via InstrumentationRegistry. où la configuration contextuelle et environnementale créée par le framework d'instrumentation stockées. Grâce à ce cours, vous pouvez également appeler:

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

Compiler et tester en local

Pour les cas d'utilisation les plus courants, utilisez Confirmer :

Pour les cas plus complexes nécessitant une personnalisation plus poussée, suivez le instructions d'instrumentation.