Esegui test in Android Studio e I test dalla riga di comando spiegano come impostare configurare ed eseguire configurazioni di test di base. Tuttavia, quando la tua app e le relative requisiti dei test diventano più avanzati, potrebbe essere necessario adattare ulteriori configurazioni. Ad esempio, potresti aver bisogno di una configurazione di test avanzata devi effettuare le seguenti operazioni:
- Esegui test con strumenti solo per una variante di build specifica o sostituiscine le impostazioni del file manifest.
- Cambia il tipo di build su cui vengono eseguiti i test o configura il relativo Gradle le opzioni di CPU e memoria disponibili.
- Estrai i test con strumenti nel relativo modulo di test.
- Eseguire test più avanzati durante la configurazione dell'integrazione continua.
In questa pagina vengono descritti i vari modi per configurare i test quando l'impostazione predefinita le impostazioni non soddisfano le tue esigenze.
Crea un test instrumentato per una variante di build
Se il progetto include varianti della build con di origini uniche, potresti voler includere test strumentati che corrispondono a questi insiemi di origini. In questo modo il codice del test è organizzato consente di eseguire solo i test applicabili a una determinata variante di build.
Per collegare i test instrumentati a una variante della build, inseriscili in una propria
insieme di origini, situato in
src/androidTestVariantName
.
I test strumentati nel set di origini src/androidTest/
sono condivisi da tutti
creare varianti. Quando crei un APK di prova per "MyFlavor" la variante del tuo
dell'app, Gradle combina src/androidTest/
e src/androidTestMyFlavor/
set di origini dati.
Per aggiungere un set di origini di test per la variante di build in Android Studio: questi passaggi:
- Nella finestra Progetto, fai clic sul menu e seleziona la vista Progetto.
- Nella cartella del modulo appropriata, fai clic con il tasto destro del mouse sulla cartella src e fai clic su Nuovo > Google Cloud.
- Come nome della directory, inserisci "androidTestVariantName". Ad esempio, se
c'è una variante di build chiamata "MyFlavor", utilizza il nome della directory
androidTestMyFlavor
. - Fai clic su OK.
- Fai clic con il pulsante destro del mouse sulla nuova directory e seleziona Nuovo > Google Cloud.
- Inserisci "java" come nome della directory, quindi fai clic su OK.
Ora puoi aggiungere test a questo nuovo set di origini seguendo le passaggi per aggiungere un nuovo test. Quando raggiungi la finestra di dialogo Scegli directory di destinazione, seleziona la nuova set di origini test delle varianti.
La tabella seguente mostra un esempio di come i file di test di strumentazione potrebbero risiedono in set di codice sorgente che corrispondono a quelli dell'app:
Tabella 1. Codice sorgente dell'app e corrispondente file di test della strumentazione
Percorso della classe app | Percorso della classe di test della strumentazione corrispondente |
---|---|
src/main/java/Example.java
|
src/androidTest/java/AndroidExampleTest.java
|
src/myFlavor/java/Example.java
|
src/androidTestMyFlavor/java/AndroidExampleTest.java
|
Proprio come per i set di origini delle app, la build di Gradle si unisce e
esegue l'override dei file di diversi set di origini di test. In questo caso,
AndroidExampleTest.java
file nel set di origini androidTestMyFlavor
esegue l'override
la versione nel set di origini androidTest
. Questo perché
l'insieme di origini flavor del prodotto ha la priorità sul set di origini principale.
Quando selezioni versioni diverse nel selettore delle varianti di build,
le cartelle androidTest
appropriate vengono mostrate nella visualizzazione Android per
mostra le cartelle che vengono utilizzate:
![Variante MyFlavor selezionata e cartella androidTestMyFlavor visualizzata
nella vista Android](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-android-view.png?hl=it)
MyFlavor
variante selezionata; il
Nella visualizzazione Android viene mostrata la cartella androidTestMyFlavor
.La cartella androidTestMyFlavor
non viene mostrata quando è presente una variante diversa
selezionato:
![È selezionata la variante OtherFlavor e la cartella androidTestMyFlavor non lo è
mostrato nella vista Android](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-android-view.png?hl=it)
OtherFlavor
variante selezionata; il
La cartella androidTestMyFlavor
non viene mostrata nella visualizzazione Android.Questo aspetto avrà un aspetto leggermente diverso se utilizzi la vista Progetto, ma non dell'IA:
![La variante MyFlavor selezionata e la cartella androidTestMyFlavor è attiva
nella vista Progetto](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-project-view.png?hl=it)
MyFlavor
variante selezionata; il
La cartella androidTestMyFlavor
è attiva nella visualizzazione Progetto.Quando è selezionata una variante diversa, la cartella androidTestMyFlavor
è ancora
visibile, ma non viene indicato come attivo:
![È selezionata la variante OtherFlavor e la cartella androidTestMyFlavor non lo è
attivi nella vista progetto](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-project-view.png?hl=it)
OtherFlavor
variante selezionata; il
La cartella androidTestMyFlavor
non è attiva nella visualizzazione Progetto.Per saperne di più su come vengono uniti i set di origini, consulta Set di origini.
Configura le impostazioni del manifest della strumentazione
I test strumentati sono integrati in un APK separato con un
AndroidManifest.xml
. Quando Gradle crea l'APK di test,
genera automaticamente il file AndroidManifest.xml
e lo configura
con
<instrumentation>
.
Uno dei motivi per cui Gradle configura questo nodo per te è assicurarsi che
targetPackage
specifica il nome di pacchetto corretto dell'app sottoposta a test.
Per modificare altre impostazioni per questo nodo, crea un altro
file manifest nel set di origine di test oppure configura il file a livello di modulo
build.gradle
file, come mostrato in
nel seguente esempio di codice. L'elenco completo delle opzioni è disponibile nella
BaseFlavor
Riferimento API.
Alla moda
android { ... defaultConfig { ... testApplicationId "com.example.test" testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner" testHandleProfiling true testFunctionalTest true } }
Kotlin
android { ... defaultConfig { ... testApplicationId = "com.example.test" testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner" testHandleProfiling = true testFunctionalTest = true } }
Each product flavor you configure can override properties in the
defaultConfig {}
block. To learn more, go to Configure product
flavors.
The properties in the snippet are:
Setting | Description |
---|---|
testApplicationId
|
Specifies the application ID for the test APK. |
testInstrumentationRunner
|
Specifies the fully qualified class name of the test instrumentation runner. |
testHandleProfiling
|
If set to true , enables the instrumentation class
to start and stop profiling.If set to false , profiling occurs the entire time
the instrumentation class is running. |
testFunctionalTest
|
If set to true , indicates that the Android system
should run the instrumentation class as a functional
test.The default value is false . |
Change the test build type
By default, all instrumentation tests run against the debug
build type.
You can change this to another build type by using the testBuildType
property in your module-level build.gradle
file. For example, if you want
to run your tests against your staging
build type, edit the file as
shown in the following snippet:
Groovy
android { ... testBuildType "staging" }
Kotlin
android { ... testBuildType = "staging" }
Configura le opzioni del test Gradle
Il plug-in Android Gradle ti consente di
specificare determinate opzioni per tutti i test o solo per alcuni. Nella
file build.gradle
a livello di modulo, usa
testOptions
blocco per specificare le opzioni che cambiano il modo in cui Gradle esegue tutti i tuoi test:
Alla moda
android { ... // Encapsulates options for running tests. testOptions { reportDir "$rootDir/test-reports" resultsDir "$rootDir/test-results" } }
Kotlin
android { ... // Encapsulates options for running tests. testOptions { reportDir "$rootDir/test-reports" resultsDir = "$rootDir/test-results" } }
La proprietà reportDir
cambia la directory in cui Gradle salva il test
report. Per impostazione predefinita, Gradle salva i report dei test nel
Directory path_to_your_project/module_name
/build/outputs/reports/
. $rootDir
imposta il percorso relativo
alla directory radice del progetto corrente.
La proprietà resultsDir
cambia la directory in cui Gradle salva il test
che consentono di analizzare i dati
e visualizzare i risultati. Per impostazione predefinita, Gradle salva i risultati del test nel
Directory path_to_your_project/module_name
/build/outputs/test-results/
. $rootDir
imposta il percorso relativo
alla directory radice del progetto corrente.
Per specificare le opzioni solo per i test delle unità locali, configura il
unitTests
all'interno di testOptions
.
Alla moda
android { ... testOptions { ... // Encapsulates options for local unit tests. unitTests { returnDefaultValues true all { jvmArgs '-XX:MaxPermSize=256m' if (it.name == 'testDebugUnitTest') { systemProperty 'debug', 'true' } ... } } } }
Kotlin
android { ... testOptions { ... // Encapsulates options for local unit tests. unitTests { returnDefaultValues = true all { jvmArgs = listOf("-XX:MaxPermSize=256m") if (it.name == "testDebugUnitTest") { systemProperty = mapOf("debug" to "true") } ... } } } }
Per impostazione predefinita, i test delle unità locali generano un'eccezione ogni volta che il codice
che stai testando tenta di accedere alle API della piattaforma Android, a meno che
simulazioni delle dipendenze di Android
autonomamente o con un framework di test come
Simulazione Tuttavia, puoi attivare la proprietà returnDefaultValues
in modo che
il test restituisce null o zero quando si accede alle API della piattaforma,
che generare un'eccezione.
Il blocco all
incapsula le opzioni per controllare l'esecuzione di Gradle
test delle unità locali. Per un elenco di tutte le opzioni che puoi specificare, leggi
Documentazione di riferimento di Gradle.
La proprietà jvmArgs
imposta gli argomenti JVM per le JVM di test.
Puoi anche controllare il nome dell'attività per applicare le opzioni solo ai test che
specificare. Nello snippet di esempio, la proprietà debug
è impostata su true
, ma
solo per l'attività testDebugUnitTest
.
Usa moduli di test separati per i test instrumentati
Se vuoi avere un modulo dedicato per i test instrumentati, per isolare resto del codice dai test, crea un modulo di test separato e e configurare la build in modo simile a quella di un modulo libreria.
Per creare un modulo di test, procedi come segue:
- Crea un modulo della Raccolta.
- Nel file
build.gradle
a livello di modulo, applicacom.android.test
anzichécom.android.library
. - Fai clic su Sincronizza progetto
.
Dopo aver creato il modulo di test, puoi includere il codice di test nella
set di origini principali o varianti (ad esempio src/main/java
o
src/variant/java
). Se il modulo dell'app definisce
più versioni di prodotto, puoi ricrearle nel modulo di test.
Utilizzo della dipendenza sensibile alle varianti
dell'IA,
il modulo di test tenta di testare la versione corrispondente nel modulo di destinazione.
Per impostazione predefinita, i moduli di test contengono e testano solo una variante di debug. Tuttavia,
puoi creare nuovi tipi di build
che corrispondano al progetto dell'app testata. Per fare in modo che
per il modulo di test un tipo di build diverso e non quello di debug, usa
VariantFilter
per disattivare la variante di debug nel progetto di test, come mostrato di seguito:
Alla moda
android { variantFilter { variant -> if (variant.buildType.name.equals('debug')) { variant.setIgnore(true); } } }
Kotlin
android { variantFilter { if (buildType.name == "debug") { ignore = true } } }
Se desideri che un modulo di test abbia come target solo determinate versioni o tipi di build
puoi usare l'app matchingFallbacks
per scegliere come target solo le varianti che vuoi testare. Inoltre, questo impedisce
di dover configurare le varianti autonomamente.