Alcuni moduli di test potrebbero richiedere una configurazione personalizzata e fasi di smontaggio che non possono essere eseguite all'interno del test case stesso. Esempi tipici possono includere:
- installa altri apk (oltre all'apk di prova)
- inviare alcuni file al dispositivo
- eseguire comandi (es. adb shell pm ...)
In passato, i team dei componenti di solito ricorrevano alla scrittura di un test lato host per eseguire tali attività, il che richiede la comprensione dell'imbracatura della Trade Federation e in genere aumenta la complessità di un modulo di test.
Prendendo in prestito da CTS, abbiamo introdotto il concetto di configurazione del modulo di test per supportare tali attività, l'elenco delle attività comuni sopra può essere ottenuto con poche righe di configurazione. Per la massima flessibilità, puoi persino implementare il tuo preparatore di destinazione, come definito da ITargetPreparer o ITargetCleaner , e configurarli per l'uso nella configurazione del tuo modulo di test.
Una configurazione del modulo di test per un modulo di test è un file XML richiesto aggiunto alla cartella di origine del modulo di livello superiore, denominata "AndroidTest.xml". L'XML segue il formato di un file di configurazione utilizzato dal cablaggio di automazione dei test di Trade Federation. Attualmente i tag principali gestiti tramite le configurazioni del modulo di test sono i tag "target_preparer" e "test".
Preparatori di obiettivi
Un tag "target_preparer", come suggerisce il nome, definisce un preparatore di destinazione (vedi ITargetPreparer ) che offre un metodo di configurazione, che viene chiamato prima che il modulo di test venga eseguito per il test; e se la classe a cui si fa riferimento nel tag "target_preparer" implementa anche ITargetCleaner , il suo metodo di smontaggio verrà invocato al termine del modulo di test.
Per utilizzare la configurazione del modulo comune integrata, aggiungi un nuovo file "AndroidTest.xml" nella cartella di livello superiore per il modulo di test e popolalo con il seguente contenuto:
<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>
Ad esempio, possiamo aggiungere i seguenti tag di opzione (nel commento "inserisci" sopra):
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="settings put secure accessibility_enabled 1" />
<option name="teardown-command" value="settings put secure accessibility_enabled 0" />
</target_preparer>
Le opzioni configureranno il cablaggio di prova per:
- prima che il modulo di test venga invocato, eseguire il comando shell "settings put secure accessibility_enabled 1" sul dispositivo
- dopo che il modulo di test è terminato, esegui il comando della shell "impostazioni mettere accesso sicuro_abilitato 0"
In questo particolare esempio, l'accessibilità è abilitata/disabilitata rispettivamente prima/dopo l'esecuzione del modulo di test. Con un semplice esempio dimostrato, è necessario coprire maggiori dettagli su come viene utilizzato il tag "opzione". Come mostrato sopra, il tag può avere due attributi: nome, valore. L'attributo name indicava il nome dell'opzione ed è ulteriormente suddiviso in due parti separate da due punti: nome abbreviato per il preparatore e il nome effettivo dell'opzione offerto dal preparatore.
Lo scopo esatto del campo valore dipende da come il preparatore ha definito l'opzione: può essere una stringa, un numero, un booleano o anche un percorso di file ecc. Nell'esempio sopra, il nome "run-command:run-command" significa che stiamo impostando il valore per l'opzione “run-command” definita da un preparatore di destinazione con il nome abbreviato “run-command”; e il nome “run-command:teardown-command” significa che stiamo impostando il valore per l'opzione “teardown-command” definita anche dallo stesso preparatore del target con il nome abbreviato “run-command”. Ecco un riepilogo dei tre preparatori di obiettivi comuni:
nome della classe: PushFilePreparer
- nome breve : file push
- funzione : spinge file arbitrari nella cartella test case nella destinazione sul dispositivo
- note :
- questo preparatore può eseguire il push da una cartella all'altra o da un file all'altro; ovvero, non puoi eseguire il push di un file in una cartella sul dispositivo: devi specificare anche il nome del file di destinazione in quella cartella
- opzioni :
- push-file: una specifica push, che specifica il file locale nel percorso in cui deve essere eseguito il push sul dispositivo. Può essere ripetuto. Se più file sono configurati per essere inviati allo stesso percorso remoto, verrà eseguito il push dell'ultimo.
- push: (obsoleto) Una specifica push, formattata come '
/path/to/srcfile.txt->/path/to/destfile.txt' o '/path/to/srcfile.txt->/path/to/destdir/'. Può essere ripetuto. Questo percorso può essere relativo alla directory del modulo di test o alla directory out stessa. - post-push: un comando da eseguire sul dispositivo (con `
adb shell <your command>`) dopo che tutti i push sono stati tentati. Un tipico caso d'uso sarebbe l'utilizzo di chmod per le autorizzazioni
nome della classe: InstallApkSetup
- nome breve: install-apk
- funzione: spinge i file apk arbitrari nella destinazione sul dispositivo
- opzioni:
- nome-file-test: il nome dell'apk da installare sul dispositivo.
- install-arg: argomenti aggiuntivi da passare al comando pm install, incluso il trattino iniziale, ad esempio "-d". Può essere ripetuto
nome della classe: RunCommandTargetPreparer
- nome breve: comando di esecuzione
- funzione: esegue comandi shell arbitrari prima o dopo l'esecuzione del modulo di test
- opzioni:
- run-command: comando adb shell da eseguire. Può essere ripetuto
- teardown-command: comando adb shell da eseguire durante la fase di teardown. Può essere ripetuto
Classe di prova
Una classe test è la classe Trade Federation da utilizzare per eseguire il test.
<test class="com.android.tradefed.testtype.AndroidJUnitTest">
<option name="package" value="android.test.example.helloworld"/>
<option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>
Ecco tre classi di test comuni:
nome della classe: GTest
- nome breve: gtest
- funzione: un test che esegue un pacchetto di test nativo su un determinato dispositivo.
- opzioni:
- native-test-device-path: il percorso sul dispositivo in cui si trovano i test nativi.
nome della classe: InstrumentationTest
- nome breve: strumentazione
- funzione: un test che esegue un pacchetto di test della strumentazione su un determinato dispositivo
- opzioni:
- pacchetto: il nome del pacchetto manifest dell'applicazione di test Android da eseguire.
- class: il nome della classe di test da eseguire.
- metodo: il nome del metodo di test da eseguire.
nome della classe: AndroidJUnitTest
- funzione: un test che esegue un pacchetto di test della strumentazione su un determinato dispositivo utilizzando android.support.test.runner.AndroidJUnitRunner Questo è il modo principale per eseguire un test della strumentazione.