Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Targeting di un esempio di applicazione

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

Questa guida presuppone che tu abbia già alcune conoscenze nel flusso di lavoro dell'albero dei sorgenti della piattaforma. In caso contrario, fare riferimento a https://source.android.com/source/requirements. L'esempio qui trattato sta scrivendo un nuovo test di strumentazione con il pacchetto target impostato nel proprio pacchetto dell'applicazione di test. Se non si ha familiarità con il concetto, leggere l' introduzione alla verifica della piattaforma .

Questa guida utilizza il seguente test per servire da esempio:

  • framework / Base / pacchetti / Shell / prove

Si consiglia di consultare prima il codice per ottenere un'impressione approssimativa prima di procedere.

Decidere una posizione di origine

Poiché il test di strumentazione sarà destinato a un'applicazione, la convenzione prevede di posizionare il codice sorgente del test in una directory dei tests sotto la radice della directory dei componenti del componente nella struttura dei sorgenti della piattaforma.

Vedi altre discussioni sulla posizione della fonte nell'esempio end-to-end per i test di auto-strumentazione .

File manifest

Proprio come un'applicazione normale, ogni modulo di test di strumentazione necessita di un file manifest. Se assegni il file come AndroidManifest.xml e lo fornisci accanto ad Android.mk per il tuo modulo di test, verrà incluso automaticamente dal makefile principale BUILD_PACKAGE .

Prima di procedere oltre, si consiglia vivamente di consultare prima la Panoramica del manifest dell'app .

Ciò 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 di esempio di gerrit 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>
 

Alcuni commenti selezionati sul file manifest:

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

L'attributo del package è il nome del pacchetto dell'applicazione: questo è l'identificatore univoco che il framework dell'applicazione Android utilizza 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 dell'applicazione di test, indipendente dal pacchetto dell'applicazione in prova, è necessario utilizzare un nome pacchetto diverso: una convenzione comune è quella di aggiungere un suffisso .test .

Inoltre, questo attributo del package è lo stesso di quello che restituisce ComponentName#getPackageName() e lo stesso che ComponentName#getPackageName() per interagire con vari sottocomandi pm tramite la adb shell .

Si noti inoltre che sebbene il nome del pacchetto sia generalmente nello stesso stile di un nome pacchetto Java, in realtà ha pochissime cose a che fare con esso. In altre parole, il pacchetto dell'applicazione (o test) può contenere classi con qualsiasi nome di pacchetto, sebbene, d'altra parte, si potrebbe optare per la semplicità e avere il nome del pacchetto Java di livello superiore 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 di percorso di classe aggiuntive quando il pacchetto di test viene richiamato dal framework dell'applicazione.

 android:targetPackage="com.android.shell"
 

Questo imposta il pacchetto target della strumentazione su com.android.shell.tests . Quando la strumentazione viene invocata tramite il comando am instrument , il framework riavvia il processo com.android.shell.tests e inserisce il codice della strumentazione nel processo per l'esecuzione del test. Ciò significa anche che il codice di test avrà accesso a tutte le istanze di classe in esecuzione nell'applicazione sotto test e potrebbe essere in grado 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 del modulo, dipendenze in fase di compilazione e istruzioni di impacchettamento. Nella maggior parte dei casi, l'opzione del file Blueprint basata su Soong è sufficiente. Vedere Configurazione test semplice per dettagli.

File di configurazione complesso

Per test più complessi, è inoltre necessario scrivere un file di configurazione di test per il cablaggio di test di Android, Trade Federation .

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

È possibile accedere all'ultima versione del file di configurazione per la modifica di esempio di gerrit su: frameworks / 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>
 

Alcuni commenti selezionati sul file di configurazione del test:

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

Ciò indica a Trade Federation di installare ShellTests.apk sul dispositivo di destinazione utilizzando target_preparer specificato. Esistono molti preparatori di target 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 della Federazione commerciale da utilizzare per eseguire il test e passa il pacchetto sul dispositivo da eseguire e il framework del test runner che in questo caso è JUnit.

Guarda qui per ulteriori informazioni sulle configurazioni del modulo di test

Funzionalità di JUnit4

L'uso della libreria android-support-test come test runner consente l'adozione di nuove classi di test in stile JUnit4 e la modifica gerrit di esempio contiene un uso molto basilare delle sue funzionalità.

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

Mentre i modelli di test sono generalmente specifici per i team di componenti, ci sono alcuni 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 per ereditare da una classe di test di base comune; invece, si scrivono test in semplici classi Java e si utilizza l'annotazione per indicare determinate impostazioni e vincoli del test. In questo esempio, stiamo ordinando che questa classe debba essere eseguita come test JUnit4 per Android.

L'annotazione @SmallTest specificato una dimensione di test per l'intera classe di test: tutti i metodi di test aggiunti in questa classe di test ereditano questa annotazione di dimensione del test. impostazione della classe pre-test, smontaggio post test e smontaggio classe post test: simile ai metodi setUp e tearDown in JUnit4. Test annotazione di Test viene utilizzata per annotare la prova effettiva.

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

L'annotazione @Before viene utilizzata sui metodi di JUnit4 per eseguire la configurazione pre-test. Anche se non utilizzato in questo esempio, c'è anche @After per lo @After post test. Allo stesso modo, le annotazioni @BeforeClass e @AfterClass possono essere utilizzate sui metodi da JUnit4 per eseguire l'installazione prima di eseguire tutti i test in una classe di test e successivamente lo smontaggio. Si noti che i metodi di installazione e smontaggio dell'ambito di classe devono essere statici.

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

         Context context = InstrumentationRegistry.getTargetContext();
 

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

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

Costruisci e testa localmente

Per i casi d'uso più comuni, utilizzare Atest .

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