Configurazione avanzata dei test

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:

1. Nella finestra Progetto, fai clic sul menu e seleziona la vista Progetto.
2. Nella cartella del modulo appropriata, fai clic con il tasto destro del mouse sulla cartella src e fai clic su Nuovo > Google Cloud.
3. Come nome della directory, inserisci "androidTestVariantName". Ad esempio, se c'è una variante di build chiamata "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 > Google Cloud.
6. 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:

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

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

Figura 2. 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:

Figura 3. 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:

Figura 4. 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:

1. Crea un modulo della Raccolta.
2. Nel file build.gradle a livello di modulo, applica 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 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.