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 suoi requisiti di test diventano più avanzati, potrebbe essere necessario adattare ulteriormente le configurazioni di test. Ad esempio, potrebbe essere necessaria la configurazione avanzata di test quando vuoi eseguire le seguenti operazioni:

• Esegui test strumentali 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 configura le relative opzioni Gradle.
• Estrai i tuoi test strumentati nel relativo modulo di test.
• Esegui test più avanzati nell'ambito della configurazione dell'integrazione continua.

In questa pagina vengono descritti vari modi per configurare i test quando le impostazioni predefinite non soddisfano le tue esigenze.

Creare un test strumentato per una variante build

Se il tuo progetto include varianti della build con set di origini univoci, puoi 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, situato all'indirizzo src/androidTestVariantName.

I test strumentali nel set di origine src/androidTest/ sono condivisi da tutte le varianti della build. Durante la creazione di un APK di test per la variante "MyFlavor" dell'app, Gradle combina i set di origini src/androidTest/ e src/androidTestMyFlavor/.

Per aggiungere un set di origine di test per la variante build in Android Studio, segui questi passaggi:

1. Nella finestra Progetto, fai clic sul menu e seleziona la visualizzazione Progetto.
2. All'interno della 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 Nuovo > Directory.
6. Inserisci "java" come nome della directory, quindi fai clic su OK.

Ora puoi aggiungere test a questo nuovo set di origini seguendo la procedura per aggiungere un nuovo test. Nella 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 della strumentazione potrebbero trovarsi in set di origini corrispondenti ai set di origini di codice dell'app:

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

Percorso della classe 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 delle app, la build di Gradle unisce e sostituisce i file provenienti da set di origini di test diversi. 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 origine dei gusti del prodotto ha la priorità sul set di origine principale.

Quando selezioni versioni diverse nel selettore delle varianti di build, vengono visualizzate le cartelle androidTest appropriate nella visualizzazione di Android 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 viene selezionata una variante diversa:

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

Questo sembra leggermente diverso se utilizzi la vista Progetto, ma viene applicato lo stesso principio:

Figura 3. MyFlavor variante selezionata; la cartella androidTestMyFlavor è attiva nella visualizzazione 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 origine.

Configura le impostazioni del file manifest di strumentazione

I test strumentali sono integrati in un APK separato con il proprio file AndroidManifest.xml. Quando Gradle crea il tuo 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 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"
}

Configura 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 opzioni che modificano 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 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 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 imuli le dipendenze Android o 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 strumentali, 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, procedi come segue:

1. Crea un modulo della raccolta.
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 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 app testato. Per fare in modo che il modulo di test testi un tipo di build diverso e non quello di debug, utilizza 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 alcune 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.