Configurazione avanzata dei test

I contenuti di Test in Android Studio e Test dalla riga di comando spiegano come configurare ed eseguire le configurazioni di test di base. Tuttavia, quando l'app e i relativi requisiti di test diventano più avanzati, potrebbe essere necessario adattare ulteriormente le configurazioni di test. Ad esempio, potresti aver bisogno di una configurazione di test avanzata quando vuoi:

• Eseguire test di strumentazione solo per una variante di compilazione specifica o sostituire le impostazioni del manifest.
• Modificare il tipo di compilazione su cui vengono eseguiti i test o configurare le opzioni Gradle.
• Estrarre i test di strumentazione nel proprio modulo di test.
• Eseguire test più avanzati nell'ambito della configurazione dell'integrazione continua.

Questa pagina descrive vari modi per configurare i test quando le impostazioni predefinite non soddisfano le tue esigenze.

Creare un test di strumentazione per una variante di compilazione

Se il progetto include varianti di build con set di origine univoci, potresti voler includere test di strumentazione che corrispondono a questi set di origine. In questo modo, il codice di test rimane organizzato e puoi eseguire solo i test che si applicano a una determinata variante di compilazione.

Per collegare i test di instrumentazione a una variante di compilazione, inseriscili nel proprio set di risorse, che si trova in src/androidTestVariantName.

I test strumentati nel set di risorse src/androidTest/ sono condivisi da tutte le varianti di compilazione. Quando Gradle crea un APK di test per la variante "MyFlavor" della tua app, combina i set di origine src/androidTest/ e src/androidTestMyFlavor/.

Per aggiungere un set di risorse di test per la variante di compilazione in Android Studio:

1. Nella finestra Progetto, fai clic sul menu e seleziona la visualizzazione Progetto.
2. Nella cartella del modulo appropriata, fai clic con il tasto destro del mouse sulla cartella src e scegli Nuovo > Directory.
3. Per il nome della directory, inserisci "androidTestVariantName." Ad esempio, se hai una variante di compilazione denominata "MyFlavor", utilizza il nome della directory androidTestMyFlavor.
4. Fai clic su OK.
5. Fai clic con il tasto destro del mouse sulla nuova directory e seleziona Nuovo > Directory.
6. Inserisci "java" come nome della directory, quindi fai clic su OK.

Ora puoi aggiungere test a questo nuovo set di risorse seguendo i passaggi per aggiungere un nuovo test. Quando raggiungi la finestra di dialogo Scegli directory di destinazione, seleziona il nuovo set di risorse di test della variante.

La tabella seguente mostra un esempio di come i file di test di strumentazione potrebbero risiedere nei set di origine che corrispondono ai set di origine del codice dell'app:

Tabella 1. Codice sorgente dell'app e file di test di strumentazione corrispondenti

Come per i set di origine dell'app, la build Gradle unisce e sostituisce i file di diversi set di origine di test. In questo caso, il AndroidExampleTest.kt file nel set di origine androidTestMyFlavor sostituisce la versione nel set di origine androidTest. Questo perché il set di risorse della versione prodotto ha la priorità sul set di risorse principale.

Quando selezioni varianti diverse nel selettore delle varianti di build, le cartelle androidTest appropriate vengono visualizzate nella visualizzazione Android per mostrare le cartelle utilizzate:

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

L'aspetto è leggermente diverso se utilizzi la visualizzazione Progetto, ma si applica lo stesso principio:

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

Per ulteriori informazioni su come vengono uniti i set di origine, consulta Set di origine.

Configurare le impostazioni del manifest di strumentazione

I test di strumentazione vengono creati in un APK separato con il proprio file AndroidManifest.xml. Quando Gradle crea l'APK di test, lo genera automaticamente il file AndroidManifest.xml e lo configura con il <instrumentation> nodo. Uno dei motivi per cui Gradle configura questo nodo è assicurarsi che la targetPackage proprietà specifichi il nome del pacchetto corretto dell'app in fase di test.

Per modificare altre impostazioni per questo nodo, crea un altro file manifest nel set di risorse di test o configura il file build.gradle a livello di modulo, come mostrato nel seguente esempio di codice. L'elenco completo delle opzioni è disponibile nella BaseFlavor documentazione di riferimento dell'API.

android {
    ...
    defaultConfig {
        ...
        testApplicationId = "com.example.test"
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling = true
        testFunctionalTest = true
    }
}

android {
    ...
    defaultConfig {
        ...
        testApplicationId "com.example.test"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling true
        testFunctionalTest true
    }
}

Ogni versione prodotto che configuri può sostituire le proprietà nel blocco defaultConfig {}. Per saperne di più, vai a Configurare le varianti di prodotto.

Le proprietà nello snippet sono:

Modificare il tipo di build di test

Per impostazione predefinita, tutti i test di instrumentazione vengono eseguiti sul tipo di compilazione debug. Puoi modificarlo in un altro tipo di compilazione utilizzando la proprietà testBuildType nel file build.gradle a livello di modulo. Ad esempio, se vuoi eseguire i test sul tipo di compilazione staging, modifica il file come mostrato nel seguente snippet:

android {
    ...
    testBuildType = "staging"
}

android {
    ...
    testBuildType "staging"
}

Configurare le opzioni di test di Gradle

Il plug-in Android per Gradle ti consente di specificare determinate opzioni per tutti o solo alcuni dei tuoi test. Nel file a livello di modulo, utilizza il testOptions blocco per specificare le opzioni che modificano il modo in cui Gradle esegue tutti i test:build.gradle

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir = "$rootDir/test-reports"
        resultsDir = "$rootDir/test-results"
    }
}

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir "$rootDir/test-reports"
        resultsDir "$rootDir/test-results"
    }
}

La proprietà reportDir modifica la directory in cui Gradle salva i report di test. Per impostazione predefinita, Gradle salva i report di 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 modifica la directory in cui Gradle salva i risultati dei test. Per impostazione predefinita, Gradle salva i risultati dei 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 unitTests blocco all'interno di testOptions.

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")
                }
                ...
            }
        }
    }
}

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues true

            all {
                jvmArgs '-XX:MaxPermSize=256m'

                if (it.name == 'testDebugUnitTest') {
                    systemProperty 'debug', '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 autonomamente o con un framework di test come Mockito. Tuttavia, puoi attivare la proprietà returnDefaultValues in modo che il test restituisca null o zero quando accede alle API della piattaforma, anziché generare un'eccezione.

Il blocco all incapsula 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, consulta 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 che specifichi. Nello snippet di esempio, la proprietà debug è impostata su true, ma solo per l'attività testDebugUnitTest.

Utilizzare moduli di test separati per i test di strumentazione

Se vuoi avere un modulo dedicato ai test di strumentazione, per isolare il resto del codice dai test, crea un modulo di test separato e configura la build in modo simile a quella di un modulo della 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 risorse principale o della variante (ad esempio, src/main/kotlin+java o src/variant/kotlin+java). Se il modulo dell'app definisce più versioni prodotto, puoi ricrearle nel modulo di test. Utilizzando la gestione delle dipendenze con riconoscimento delle varianti, il modulo di test tenta di testare la variante 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 in modo che corrispondano al progetto dell'app testata. Per fare in modo che il modulo di test testi un tipo di compilazione diverso da quello di debug, utilizza VariantFilter per disattivare la variante di debug nel progetto di test, come mostrato di seguito:

android {
    variantFilter {
        if (buildType.name == "debug") {
            ignore = true
        }
    }
}

android {
    variantFilter { variant ->
        if (variant.buildType.name.equals('debug')) {
            variant.setIgnore(true);
        }
    }
}

Se vuoi che un modulo di test abbia come target solo determinate varianti o tipi di build di un'app, puoi utilizzare la proprietà matchingFallbacks per scegliere come target solo le varianti che vuoi testare. In questo modo, il modulo di test non deve configurare queste varianti autonomamente.