Targeting di un esempio di applicazione

Questa categoria di test della strumentazione non è molto diversa da quelle destinate alle normali applicazioni Android. Vale la pena notare che l'applicazione di test che include la strumentazione deve essere firmata con lo stesso certificato dell'applicazione a cui è destinata.

Tieni presente che questa guida presuppone che tu abbia già una certa conoscenza del flusso di lavoro dell'albero di origine della piattaforma. In caso contrario, fare riferimento a https://source.android.com/source/requirements. L'esempio qui trattato consiste nella scrittura di un nuovo test della strumentazione con il pacchetto di destinazione impostato sul proprio pacchetto dell'applicazione di test. Se non si ha familiarità con il concetto, si prega di leggere attraverso l' introduzione test piattaforma .

Questa guida utilizza il seguente test come esempio:

  • framework/base/pacchetti/Shell/test

Si consiglia di sfogliare prima il codice per avere un'idea approssimativa prima di procedere.

Decidere su una posizione di origine

Poiché il test strumentazione punterà un'applicazione, la convenzione è quello di mettere il codice sorgente di prova in un tests directory sotto la radice della directory di origine componente nella struttura di origine piattaforma.

Vedere discussioni sulla posizione di origine nel esempio end-to-end per le prove di auto-strumentazione .

File manifest

Proprio come una normale applicazione, ogni modulo di test della strumentazione necessita di un file manifest. Se è il nome del file come AndroidManifest.xml e fornirlo accanto al Android.mk per il vostro Tmodule di prova, si otterrà automaticamente inclusi dal BUILD_PACKAGE makefile nucleo.

Prima di procedere oltre, è altamente raccomandato di passare attraverso l' App manifesto Panoramica prima.

Questo fornisce una panoramica dei componenti di base di un file manifest e delle loro funzionalità.

È possibile accedere all'ultima versione del file manifest per la modifica gerrit di esempio all'indirizzo: https://android.googlesource.com/platform/frameworks/base/+/master/packages/Shell/tests/AndroidManifest.xml

Un'istantanea è inclusa qui per comodità:

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

Alcune note selezionate sul file manifest:

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

Il package attributo è il nome del pacchetto di applicazione: questo è l'identificatore univoco che utilizza il framework di applicazioni Android per identificare un'applicazione (o in questo contesto: l'applicazione di test). Ogni utente nel sistema può installare solo un'applicazione con quel nome di pacchetto.

Poiché si tratta di un pacchetto di applicazione di test, indipendente dal pacchetto di applicazione in prova, un nome pacchetto diverso deve essere utilizzato: una convenzione comune è quello di aggiungere un suffisso .test .

Inoltre, questo package attributo è lo stesso di quello ComponentName#getPackageName() ritorna, e anche la stessa si usa per interagire con i vari pm comandi secondario via adb shell .

Si noti inoltre che, sebbene il nome del pacchetto sia in genere nello stesso stile del nome di un pacchetto Java, in realtà ha pochissime cose a che fare con esso. In altre parole, il pacchetto dell'applicazione (o del test) può contenere classi con qualsiasi nome di pacchetto, sebbene, d'altra parte, si possa optare per la semplicità e avere il nome del pacchetto Java di primo livello nell'applicazione o test identico al nome del pacchetto dell'applicazione.

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

Ciò è necessario per tutti i test di Strumentazione poiché le classi correlate sono impacchettate in un file di libreria jar del framework separato, pertanto richiede voci del percorso di classe aggiuntive quando il pacchetto di test viene richiamato dal framework dell'applicazione.

android:targetPackage="com.android.shell"

Imposta il pacchetto di destinazione della strumentazione per com.android.shell . Quando la strumentazione viene richiamata mediante am instrument comando, il riavvio del quadro com.android.shell processo, e il codice inietta strumentazione nel processo per l'esecuzione di test. Ciò significa anche che il codice di test avrà accesso a tutte le istanze di classe in esecuzione nell'applicazione sottoposta a test e potrebbe essere in grado di manipolare lo stato in base agli hook di test esposti.

File di configurazione semplice

Ogni nuovo modulo di test deve avere un file di configurazione per dirigere il sistema di compilazione con i metadati del modulo, le dipendenze in fase di compilazione e le istruzioni di confezionamento. Nella maggior parte dei casi, l'opzione del file Blueprint basata su Soong è sufficiente. Vedere Configurazione di test semplice per i dettagli.

File di configurazione complesso

Per le prove più complesse, è inoltre necessario scrivere un file di configurazione di prova per il test harness di Android, Federazione dei Mercanti .

La configurazione del test può specificare opzioni di configurazione del dispositivo speciali e argomenti predefiniti per fornire la classe di test.

L'ultima versione del file di configurazione per il cambiamento Gerrit del campione è possibile accedere in: quadri / base / pacchetti / Shell / test / AndroidTest.xml

Un'istantanea è inclusa qui per comodità:

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

Alcune note di selezione sul file di configurazione del test:

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

Questo dice a Trade Federation di installare ShellTests.apk sul dispositivo di destinazione utilizzando un target_preparer specificato. Ci sono molti preparatori di destinazione disponibili per gli sviluppatori in Trade Federation e questi possono essere utilizzati per garantire che il dispositivo sia configurato correttamente prima dell'esecuzione del 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>

Questo specifica la classe di test di Trade Federation da utilizzare per eseguire il test e passa nel pacchetto sul dispositivo da eseguire e il framework di test runner che è JUnit in questo caso.

Guardate qui per maggiori informazioni sul modulo di prova Configs

Funzionalità JUnit4

Utilizzando android-support-test biblioteca come prova corridore consente adoptation di nuove classi di test stile JUnit4, e il cambiamento Gerrit campione contiene un certo uso molto di base delle sue caratteristiche.

Ultimo codice sorgente per il cambiamento gerrit campione può essere letta in: quadri / base / packages / Shell / test / src / com / android / shell / BugreportReceiverTest.java

Sebbene i modelli di test siano in genere specifici per i team dei componenti, esistono alcuni modelli di utilizzo generalmente utili.

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

Una differenza significativa in JUnit4 è che i test non devono più ereditare da una classe di test di base comune; invece, scrivi i test in classi Java semplici e usi l'annotazione per indicare determinate impostazioni e vincoli del test. In questo esempio, stiamo indicando che questa classe deve essere eseguita come test JUnit4 di Android.

Il @SmallTest annotazione specifica una dimensione di prova per l'intera classe di test: tutti i metodi di prova aggiunte in questa classe di test ereditano queste dimensioni delle annotazioni di prova. pre configurazione di prova di classe, dopo la prova abbattere e classe post test abbattere: simile a setUp e tearDown metodi JUnit4. Test annotazione viene utilizzato per annotare la prova effettiva.

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

Il @Before annotazione viene utilizzato su metodi di JUnit4 per eseguire la configurazione pre test. Anche se non è usato in questo esempio, c'è anche @After per test post teardown. Analogamente, i @BeforeClass e @AfterClass annotazioni vengono possono essere utilizzati su metodi di JUnit4 per eseguire la configurazione prima di eseguire tutti i test in una classe di test, e successivamente smontaggio. Si noti che i metodi di impostazione e smontaggio dell'ambito della classe devono essere statici.

Per quanto riguarda i metodi di prova, a differenza della versione precedente di JUnit, non hanno più necessità di avviare il nome del metodo con test , invece, ciascuno di essi deve essere annotato con @Test . Come al solito, i metodi di test devono essere pubblici, non dichiarare alcun valore restituito, non accettare parametri e possono generare eccezioni.

        Context context = InstrumentationRegistry.getTargetContext();

Poiché il JUnit4 non test richiedono più una classe base comune, non è più necessario per ottenere Context istanze tramite getContext() o getTargetContext() tramite metodi della classe base; invece, il nuovo test runner li gestisce tramite InstrumentationRegistry in cui è memorizzato l'installazione contestuale ed ambientale creato da quadro strumentazione. Attraverso questa classe, puoi anche chiamare:

  • getInstrumentation() : l'istanza alla Instrumentation di classe
  • getArguments() : gli argomenti della riga di comando passati a am instrument via -e <key> <value>

Crea e testa in locale

Per la maggior parte dei casi di uso comune, impiego Atest .

Per i casi più complessi che richiedono la personalizzazione più pesanti, seguire le istruzioni della strumentazione .