I test in Android Studio e i test dalla riga di comando spiegano come impostare ed eseguire configurazioni di test di base. Tuttavia, quando la tua app e i relativi requisiti di test diventano più avanzati, potrebbe essere necessario adattare ulteriormente le configurazioni di test. Ad esempio, potrebbe essere necessaria la configurazione di test avanzata se vuoi eseguire le seguenti operazioni:
- Esegui test con strumenti solo per una variante di build specifica o esegui l'override delle relative impostazioni del manifest.
- Modifica il tipo di build su cui vengono eseguiti i test o configurane le opzioni Gradle.
- Estrai i tuoi test strumentati nel relativo modulo di test.
- Esegui test più avanzati nell'ambito della configurazione dell'integrazione continua.
Questa pagina descrive i vari modi per configurare i test quando le impostazioni predefinite non soddisfano le tue esigenze.
Creare un test strumentato per una variante di build
Se il tuo progetto include varianti di build con set di origini univoci, potresti voler includere test strumentati che corrispondono a questi set di origini. In questo modo il codice di test è organizzato e puoi eseguire solo i test applicabili a una determinata variante di build.
Per collegare i test strumentati a una variante di build, inseriscili nel relativo set di origine, che si trova in
src/androidTestVariantName
.
I test strumentali nel set di origine src/androidTest/
sono condivisi da tutte
le varianti della build. Quando crei un APK di test per la variante "MyFlavor" della tua app, Gradle combina i set di origine src/androidTest/
e src/androidTestMyFlavor/
.
Per aggiungere un set di origine di test per la variante della build in Android Studio, segui questi passaggi:
- Nella finestra Progetto, fai clic sul menu e seleziona la visualizzazione Progetto.
- Nella cartella del modulo appropriata, fai clic con il pulsante destro del mouse sulla cartella src e fai clic su Nuovo > Directory.
- Come nome della directory, inserisci "androidTestVariantName". Ad esempio, se hai una variante di build denominata "MyFlavor", utilizza il nome della directory
androidTestMyFlavor
. - Fai clic su OK.
- Fai clic con il pulsante destro del mouse sulla nuova directory e seleziona Nuova > Directory.
- Inserisci "java" come nome della directory e fai clic su OK.
Ora puoi aggiungere test a questo nuovo set di origine seguendo la procedura per aggiungere un nuovo test. Quando apri la finestra di dialogo Scegli directory di destinazione, seleziona il nuovo set di origini del test delle varianti.
La tabella seguente mostra un esempio di come i file di test di strumentazione potrebbero trovarsi in set di origine corrispondenti ai set di origini di codice dell'app:
Percorso del corso dell'app | Percorso della classe di test di strumentazione corrispondente |
---|---|
src/main/java/Example.java
|
src/androidTest/java/AndroidExampleTest.java
|
src/myFlavor/java/Example.java
|
src/androidTestMyFlavor/java/AndroidExampleTest.java
|
Come avviene per i set di origini dell'app, la build Gradle unisce ed esegue l'override dei file provenienti da diversi set di origini di test. In questo caso, il file AndroidExampleTest.java
nel set di origine androidTestMyFlavor
sostituisce la versione nel set di origine androidTest
. Questo perché l'insieme di origini dei gusti del prodotto ha la priorità sull'insieme di origini principale.
Quando selezioni versioni diverse nel selettore delle varianti della build, nella visualizzazione di Android vengono visualizzate le cartelle androidTest
appropriate per mostrare le cartelle utilizzate:
La cartella androidTestMyFlavor
non viene mostrata quando è selezionata una variante diversa:
L'aspetto è leggermente diverso se utilizzi la vista Progetto, ma viene applicato lo stesso principio:
Quando viene selezionata una variante diversa, la cartella androidTestMyFlavor
è ancora visibile, ma non viene mostrata come attiva:
Per ulteriori informazioni su come vengono uniti i set di origini, consulta Set di origini.
Configura le impostazioni del manifest della strumentazione
I test strumentali vengono integrati in un APK separato con il proprio file AndroidManifest.xml
. Quando Gradle crea l'APK di test, genera automaticamente il file AndroidManifest.xml
e lo configura con il nodo <instrumentation>
.
Uno dei motivi per cui Gradle configura questo nodo per te è assicurarsi che la proprietà targetPackage
specifichi il nome di pacchetto corretto dell'app in fase di test.
Per modificare altre impostazioni per questo nodo, crea un altro file manifest nel set di origini di test oppure configura il file build.gradle
a livello di modulo, come mostrato nel seguente esempio di codice. L'elenco completo delle opzioni è disponibile nel
riferimento dell'API
BaseFlavor
.
Trendy
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" }
Configurare le opzioni del test Gradle
Il plug-in Android per Gradle ti consente di specificare determinate opzioni per tutti o solo alcuni dei tuoi test. Nel
file build.gradle
a livello di modulo, utilizza il blocco
testOptions
per specificare le opzioni che cambiano il modo in cui Gradle esegue tutti i tuoi test:
Trendy
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 i report di test. Per impostazione predefinita, Gradle salva i report sui test nella directory path_to_your_project/module_name
/build/outputs/reports/
. $rootDir
imposta il percorso relativo
alla directory principale del progetto corrente.
La proprietà resultsDir
cambia la directory in cui Gradle salva i risultati
del test. Per impostazione predefinita, Gradle salva i risultati del test nella directory path_to_your_project/module_name
/build/outputs/test-results/
. $rootDir
imposta il percorso relativo
alla directory principale del progetto corrente.
Per specificare le opzioni solo per i test delle unità locali, configura il blocco unitTests
all'interno di testOptions
.
Trendy
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 tu non simuli le dipendenze Android con un framework di test come Mockito. Tuttavia, puoi abilitare la proprietà returnDefaultValues
in modo che il test restituisca un valore nullo o zero quando accedi alle API della piattaforma, anziché generare un'eccezione.
Il blocco all
include le opzioni per controllare il modo in cui Gradle esegue i test delle unità locali. Per un elenco di tutte le opzioni che puoi specificare, leggi la 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
specificati. Nello snippet di esempio, la proprietà debug
è impostata su true
, ma solo per l'attività testDebugUnitTest
.
Usa moduli di test separati per i test strumentati
Se vuoi avere un modulo dedicato per i test strumentati, per isolare il resto del codice dai test, crea un modulo di test separato e configura la sua build in modo simile a quello di un modulo libreria.
Per creare un modulo di test:
- Crea un modulo della libreria.
- Nel file
build.gradle
a livello di modulo, applica il plug-incom.android.test
anzichécom.android.library
. - Fai clic su Sincronizza progetto .
Dopo aver creato il modulo di test, puoi includere il codice di test nel
set di origine principale o di variante (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.
Utilizzando la gestione delle dipendenze sensibile alle varianti, il modulo di test tenta di testare la versione corrispondente nel modulo target.
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 di app testato. Per fare in modo che il
test del modulo con un tipo di build diverso e non quello di debug, usa
VariantFilter
per disabilitare la variante di debug nel progetto di test, come mostrato di seguito:
Trendy
android { variantFilter { variant -> if (variant.buildType.name.equals('debug')) { variant.setIgnore(true); } } }
Kotlin
android { variantFilter { if (buildType.name == "debug") { ignore = true } } }
Se vuoi che un modulo di test abbia come target solo determinate versioni o tipi di build di un'app, puoi utilizzare la proprietà matchingFallbacks
per scegliere come target solo le varianti da testare. In questo modo, inoltre,
il modulo di test non deve configurare autonomamente queste varianti.