Configurazione avanzata dei test

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:

1. Nella finestra Progetto, fai clic sul menu e seleziona la visualizzazione Progetto.
2. Nella cartella del modulo appropriata, fai clic con il pulsante destro del mouse sulla cartella src e fai clic su Nuovo > Directory.
3. Come nome della directory, inserisci "androidTestVariantName". Ad esempio, se hai una variante di build denominata "MyFlavor", utilizza il nome della directory androidTestMyFlavor.
4. Fai clic su OK.
5. Fai clic con il pulsante destro del mouse sulla nuova directory e seleziona Nuova > Directory.
6. 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:

Tabella 1. Il codice sorgente dell'app e i file di test di strumentazione corrispondenti

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:

Figura 1. MyFlavor variante selezionata; la cartella androidTestMyFlavor viene mostrata nella visualizzazione Android.

La cartella androidTestMyFlavor non viene mostrata quando è selezionata una variante diversa:

Figura 2. OtherFlavor variante selezionata; la cartella androidTestMyFlavor non viene mostrata nella visualizzazione Android.

L'aspetto è leggermente diverso se utilizzi la vista Progetto, ma viene applicato lo stesso principio:

Figura 3. MyFlavor variante selezionata; la cartella androidTestMyFlavor è attiva nella vista Progetto.

Quando viene selezionata una variante diversa, la cartella androidTestMyFlavor è ancora visibile, ma non viene mostrata come attiva:

Figura 4. OtherFlavor variante selezionata; la cartella androidTestMyFlavor non è attiva nella visualizzazione Progetto.

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:

1. Crea un modulo della libreria.
2. Nel file build.gradle a livello di modulo, applica il plug-in com.android.test anziché com.android.library.
3. 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.