Cette catégorie de tests d'instrumentation n'est pas très différente de celles ciblant les applications Android standards. Il est important de noter que l'application de test qui inclut 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 workflow de l'arborescence source de la plate-forme. Si ce n'est pas le cas, veuillez consulter la section Exigences. L'exemple présenté ici consiste à écrire un nouveau test d'instrumentation avec le package cible défini sur son propre package d'application de test. Si vous ne connaissez pas ce concept, veuillez lire l'introduction aux tests de plate-forme.
Ce guide utilise le test suivant comme exemple :
- frameworks/base/packages/Shell/tests
Nous vous recommandons de parcourir d'abord le code pour vous faire une idée générale avant de continuer.
Choisir 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 tests sous la racine du répertoire source de votre composant dans l'arborescence source de la plate-forme.
Pour en savoir plus sur l'emplacement de la source, consultez l'exemple de bout en bout pour les tests auto-instrumentés.
Fichier manifeste
Comme une application normale, 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é de Android.mk pour votre module de test, il sera inclus automatiquement par le fichier makefile principal BUILD_PACKAGE.
Avant de continuer, nous vous recommandons vivement de consulter la présentation du fichier manifeste d'application.
Vous y trouverez une présentation 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 Gerrit est disponible à l'adresse suivante : https://android.googlesource.com/platform/frameworks/base/+/android16-release/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>
Voici quelques remarques importantes 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'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 portant ce nom de package.
Comme 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, cet attribut package est identique à celui renvoyé par ComponentName#getPackageName(), et à celui que vous utiliseriez pour interagir avec diverses sous-commandes pm via adb shell.
Veuillez également noter que, bien que le nom du package soit généralement du même style qu'un nom de package Java, il n'a en fait que 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. Vous pouvez également opter pour la simplicité et avoir le nom de package Java de premier niveau dans votre application ou test identique au nom de package de l'application.
<uses-library android:name="android.test.runner" />
Cela est nécessaire pour tous les tests d'instrumentation, car les classes associées sont regroupées dans un fichier de bibliothèque jar de framework distinct. Par conséquent, des entrées de chemin de classe supplémentaires sont requises lorsque le package de test est appelé par le framework d'application.
android:targetPackage="com.android.shell"
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 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 disposer d'un fichier de configuration pour diriger le système de compilation avec les métadonnées du module, les dépendances de compilation et les instructions d'empaquetage. Dans la plupart des cas, l'option de fichier Blueprint basée sur Soong est suffisante. Pour en savoir plus, consultez Configuration simple des tests.
Fichier de configuration complexe
Pour les tests plus complexes, vous devez également écrire un fichier de configuration de test pour le harnais de test d'Android, Trade Federation.
La configuration de test peut spécifier des options spéciales de configuration de l'appareil et des arguments par défaut à fournir à la classe de test.
La dernière version du fichier de configuration pour l'exemple de modification Gerrit est accessible à l'adresse suivante : 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>
Voici quelques remarques sur 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 à Trade Federation d'installer ShellTests.apk sur l'appareil cible à l'aide d'un target_preparer spécifié. De nombreux préparateurs de cibles sont disponibles pour les développeurs dans Trade Federation. Ils peuvent être utilisés pour s'assurer que l'appareil est correctement configuré avant l'exécution des tests.
<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 l'appareil à exécuter ainsi que le framework de l'exécuteur de test, qui est JUnit dans ce cas.
Pour en savoir plus sur les configurations du module de test, cliquez ici.
Fonctionnalités JUnit4
L'utilisation de la bibliothèque android-support-test comme exécuteur de tests permet l'adoption de nouvelles classes de test de style JUnit4. L'exemple de modification Gerrit contient une utilisation très basique de ses fonctionnalités.
Le dernier code source de l'exemple de modification Gerrit est accessible à 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 tenus d'hériter d'une classe de test de base commune. Au lieu de cela, 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écifie une taille de test pour l'ensemble de 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 avant la classe de test, démontage après le test et démontage après la classe de test : semblable aux méthodes setUp et tearDown dans JUnit4.
L'annotation 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 par JUnit4 pour effectuer la configuration avant le test.
Bien qu'il ne soit pas utilisé dans cet exemple, il existe également @After pour la suppression après le test.
De même, les annotations @BeforeClass et @AfterClass peuvent être utilisées sur les méthodes par JUnit4 pour effectuer la configuration avant l'exécution de tous les tests d'une classe de test, et la désinstallation après. Notez que les méthodes de configuration et de nettoyage de portée de classe doivent être statiques.
Quant aux méthodes de test, contrairement aux versions antérieures de JUnit, elles n'ont plus besoin de commencer le nom de la méthode par test. Au lieu de cela, 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 générer des exceptions.
Context context = InstrumentationRegistry.getTargetContext();
Étant donné que les tests JUnit4 ne nécessitent plus de classe de base commune, il n'est plus nécessaire d'obtenir des instances Context via getContext() ou getTargetContext() via les méthodes de classe de base. Au lieu de cela, le nouveau test runner les gère via InstrumentationRegistry, où la configuration contextuelle et environnementale créée par le framework d'instrumentation est stockée. Cette classe vous permet également d'appeler :
getInstrumentation(): instance de la classeInstrumentationgetArguments(): arguments de ligne de commande transmis àam instrumentvia-e <key> <value>
Compiler et tester en local
Pour les cas d'utilisation les plus courants, utilisez Atest.
Pour les cas plus complexes nécessitant une personnalisation plus poussée, suivez les instructions d'instrumentation.