Alcuni moduli di test potrebbero richiedere una configurazione personalizzata e passaggi di eliminazione che non possono essere eseguiti all'interno dello scenario di test stesso. Ecco alcuni esempi tipici:
- installa altri APK (oltre all'APK di test)
- inviare alcuni file al dispositivo
- Esegui comandi (ad es. adb shell pm ...)
In passato, i team dei componenti di solito ricorrono a scrivere un test lato host per eseguire queste attività, il che richiede la comprensione dell'ispirazione della Trade Federation e in genere aumenta la complessità di un modulo di test .
Prendendo spunto da CTS, abbiamo introdotto il concetto di configurazione del modulo di test per supportare queste attività. L'elenco delle attività comuni riportato sopra può essere ottenuto con poche righe di configurazione. Per la massima flessibilità, puoi anche implementare il tuo preparatore di target, come definito da ITargetPreparer o ITargetCleaner, e configurarlo per l'utilizzo nella configurazione del tuo modulo di test.
La configurazione di un modulo di test è un file XML obbligatorio aggiunto alla directory di origine del modulo di primo livello, denominato "AndroidTest.xml". Il file XML segue il formato di un file di configurazione utilizzato dal kit 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 target
Un tag "target_preparer", come suggerisce il nome, definisce un preparatore del target (vedi ITargetPreparer) che offre un metodo di configurazione, chiamato prima dell'esecuzione del modulo di test per il test; e se la classe a cui fa riferimento il tag "target_preparer" implementa anche ITargetCleaner, il suo metodo di teardown 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 primo livello del modulo di test e compilalo con i seguenti contenuti:
<?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 opzione (al commento "insert" 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 framework di test in modo da:
- prima dell'esecuzione del modulo di test, esegui il comando shell "settings put secure accessibility_enabled 1" sul dispositivo
- al termine del modulo di test, esegui il comando shell "settings put secure accessibility_enabled 0"
In questo esempio specifico, l'accessibilità viene attivata/disattivata rispettivamente prima/dopo l'esecuzione del modulo di test. Dopo aver mostrato un semplice esempio, è necessario approfondire l'utilizzo del tag "option". Come mostrato sopra, il tag può avere due attributi: name e value. L'attributo name deve fare riferimento a una delle opzioni offerte dal preparatore.
Lo scopo esatto del campo del valore dipende da come il preparatore ha definito l'opzione: può essere una stringa, un numero, un valore booleano o persino un percorso file. Ecco un riepilogo dei tre responsabili di preparazione dei target più comuni:
nome della classe: PushFilePreparer
- short name: push-file
- function: invia file arbitrari nella cartella del caso di test alla destinazione sul dispositivo
- note:
- questo preparatore può eseguire il push da una cartella all'altra o da un file all'altro. Autrement dit, tu ne peux pas pousser un fichier dans une dossier sur le dispositif: tu dois également spécifier le nom de fichier de destination dans cette dossier
- opzioni:
- push-file: una specifica push che specifica il file locale per il percorso dove deve essere inviato sul dispositivo. Può essere ripetuto. Se sono configurati più file da inviare allo stesso percorso remoto, verrà inviato quello più recente.
- push: (deprecated) una specifica push, formattata come
'
/path/to/srcfile.txt->/path/to/destfile.txt' o '/path/to/srcfile.txt->/path/to/destdir/'. Può essere ripetuta. 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 aver tentato tutti i push. Un caso d'uso tipico è l'utilizzo di chmod per le autorizzazioni
nome classe: InstallApkSetup
- nome breve: install-apk
- function: invia file APK arbitrari nella destinazione sul dispositivo
- options:
- nome-file-test: il nome dell'apk da installare sul dispositivo.
- arg-install: argomenti aggiuntivi da passare al comando pm install, incluso il trattino iniziale, ad esempio "-d". Può essere ripetuto
nome della classe: RunCommandTargetPreparer
- nome breve: run-command
- function: 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 smantellamento. Può essere ripetuto
Corso di prova
Una classe di test è la classe della 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
- function: un test che esegue un pacchetto di test nativo su un determinato dispositivo.
- options:
- native-test-device-path:il percorso sul dispositivo in cui si trovano i test nativi.
nome classe: InstrumentationTest
- nome breve: instrumentation
- function: un test che esegue un pacchetto di test della strumentazione sul dispositivo specificato
- options:
- package: il nome del pacchetto manifest dell'applicazione di test Android da eseguire.
- class: il nome della classe di test da eseguire.
- method: il nome del metodo di test da eseguire.
nome della classe: AndroidJUnitTest
- function: un test che esegue un pacchetto di test di strumentazione su un determinato dispositivo utilizzando android.support.test.runner.AndroidJUnitRunner. Questo è il modo principale per eseguire un test di strumentazione.