Scegliere come target un esempio di app

Questa categoria di test di strumentazione non è poi così diversa da quelle che hanno come target le normali applicazioni per Android. Vale la pena notare che l'applicazione di test la strumentazione deve essere firmata con lo stesso certificato, come applicazione a cui è indirizzato.

Tieni presente che questa guida presuppone che tu abbia già alcuna conoscenza del del flusso di lavoro della struttura di origine della piattaforma. In caso contrario, consulta i Requisiti. L'esempio illustrato qui è la scrittura di un nuovo test di strumentazione con target nel proprio pacchetto di applicazioni di test. Se non hai familiarità con il concetto, leggi la Introduzione ai test della piattaforma.

Questa guida utilizza il seguente test come esempio:

• frameworks/base/packages/Shell/test

Ti consigliamo di esaminare prima il codice per ottenere un'impressione approssimativa prima di procedere.

Decidi la località di origine

Poiché il test di strumentazione prenderà di mira un'applicazione, la convenzione devi inserire il codice sorgente di test in una directory tests sotto la radice del file della directory di origine dei componenti nell'albero delle origini della piattaforma.

Leggi altre discussioni sulla posizione di origine nell'esempio end-to-end per di auto-strumentazione.

File manifest

Proprio come un'applicazione normale, ogni modulo di test della strumentazione richiede un manifest. Se assegni al file il nome AndroidManifest.xml e lo fornisci successivamente a Android.mk per il modulo di test, verrà incluso automaticamente dal Makefile principale: BUILD_PACKAGE.

Prima di procedere, consigliamo vivamente di esaminare Panoramica del file manifest dell'app per prima cosa.

Qui trovi una panoramica dei componenti di base di un file manifest e delle relative le funzionalità di machine learning.

È possibile accedere alla versione più recente del file manifest per la modifica di esempio Gerrit alle ore: https://android.googlesource.com/platform/frameworks/base/+/main/packages/Shell/tests/AndroidManifest.xml

Per praticità viene incluso qui un'istantanea:

<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 osservazioni specifiche sul file manifest:

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

L'attributo package è il nome del pacchetto dell'applicazione, ovvero l'attributo utilizzato dal framework delle applicazioni Android per identificare un (o, in questo contesto, la tua applicazione di test). Ogni utente nel sistema può installare una sola applicazione con quel nome pacchetto.

Poiché si tratta di un pacchetto di applicazioni di test, indipendente dall'applicazione pacchetto sottoposto a test, deve essere utilizzato un nome di pacchetto diverso: una convenzione comune consiste nell'aggiungere il suffisso .test.

Inoltre, questo attributo package è lo stesso restituito da ComponentName#getPackageName() e anche quello che utilizzeresti per interagire con vari comandi secondari pm tramite adb shell.

Nota anche che, sebbene il nome del pacchetto abbia in genere lo stesso stile come nome di pacchetto Java, in realtà ha pochissime cose a che fare con questo. In altre il pacchetto dell'applicazione (o di test) può contenere classi con qualsiasi pacchetto personalizzati, anche se d'altra parte, potresti optare per la semplicità e avere livello del pacchetto Java nella tua applicazione o esegui un test identico all'applicazione il nome del pacchetto.

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

Questo passaggio è obbligatorio per tutti i test di strumentazione poiché le classi correlate sono pacchettizzati in un file di libreria jar separato, pertanto richiede Voci classpath quando il pacchetto di test viene richiamato dal framework dell'applicazione.

android:targetPackage="com.android.shell"

Il pacchetto target della strumentazione viene impostato su com.android.shell. Quando la strumentazione viene richiamata tramite il comando am instrument, il framework riavvia il processo com.android.shell e inserisce il codice di strumentazione nella il processo per l'esecuzione del test. Ciò significa anche che il codice di test avrà l'accesso a tutte le istanze di classe in esecuzione nell'applicazione sottoposta a test e può la possibilità di manipolare lo stato dipende dagli hook di test esposti.

File di configurazione semplice

Ogni nuovo modulo di test deve avere un file di configurazione per indirizzare il sistema di compilazione con metadati dei moduli, dipendenze del tempo di compilazione e pacchetti istruzioni. Nella maggior parte dei casi, l'opzione File Blueprint basato su Presto è sufficienti. Per maggiori dettagli, vedi Configurazione di test semplice.

File di configurazione complesso

Per test più complessi, devi anche scrivere un file di configurazione del test per Trade Federation, l'ambiente di test di Android.

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

È possibile accedere alla versione più recente del file di configurazione per la modifica di Gerrit di esempio alle ore: frameworks/base/packages/Shell/tests/AndroidTest.xml

Per comodità, è incluso uno snapshot:

<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 osservazioni specifiche 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 indica a Trade Federation di installare ShellTests.apk sul target dispositivo utilizzando un valore target_preparer specificato. Ci sono molti preparativi del target disponibili per gli sviluppatori della Federazione commerciale e possono essere usate 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>

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

Consulta questa pagina per ulteriori informazioni sulle configurazioni dei moduli di test

Funzionalità JUnit4

L'utilizzo della libreria android-support-test come test runner consente l'adozione di nuovi classi di test in stile JUnit4 e il cambio di gerrit di esempio contiene l'uso delle sue funzionalità.

È possibile accedere al codice sorgente più recente per la modifica gerrit di esempio all'indirizzo: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java

Sebbene i pattern di test siano in genere specifici dei team dei componenti, ci sono alcune modelli di utilizzo generalmente utili.

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

Una differenza significativa in JUnit4 è che i test non sono più necessari eredita da una classe di test di base comune; Scrivi i test in Java semplice e usano l'annotazione per indicare determinati vincoli e configurazione di test. In questo esempio, dichiariamo che questa classe deve essere eseguita come test JUnit4 Android.

L'annotazione @SmallTest specificava una dimensione del test per l'intera classe di test: tutte i metodi di test aggiunti a questa classe di test ereditano questa annotazione sulle dimensioni del test. configurazione pre-testazione, rimozione post-test e rimozione post-test: simili ai metodi setUp e tearDown in JUnit4. L'annotazione Test viene utilizzata per annotare il test effettivo.

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

L'annotazione @Before viene utilizzata sui metodi di JUnit4 per eseguire la configurazione pre-test. Sebbene non venga utilizzato in questo esempio, è disponibile anche @After per l'eliminazione post-test. Analogamente, le annotazioni @BeforeClass e @AfterClass possono essere utilizzate metodi di JUnit4 per eseguire la configurazione prima di eseguire tutti i test in una classe di test, per poi procedere all'eliminazione. Nota che la configurazione dell'ambito delle classi e i metodi di eliminazione devono essere statici.

Per quanto riguarda i metodi di test, a differenza della versione precedente di JUnit, non devono più per iniziare il nome del metodo con test, ogni metodo deve essere annotato con @Test. Come al solito, i metodi di test devono essere pubblici, dichiarare nessun valore restituito non accettano parametri e possono generare eccezioni.

        Context context = InstrumentationRegistry.getTargetContext();

Poiché i test JUnit4 non richiedono più una classe base comune, necessario per ottenere le istanze Context tramite getContext() o getTargetContext() tramite metodi della classe base; il nuovo test runner le gestisce tramite InstrumentationRegistry in cui la configurazione contestuale e ambientale creata dal framework di strumentazione è archiviati. Tramite questo corso, puoi anche chiamare:

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

Creazione e test in locale

Per i casi d'uso più comuni, utilizza Conferma.

Per casi più complessi che richiedono una maggiore personalizzazione, segui le istruzioni di strumentazione.