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

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:

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

Questo aspetto avrà un aspetto leggermente diverso se utilizzi la vista Progetto, ma non dell'IA:

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

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.

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
    }
}

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:

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:

android {
    ...
    testBuildType "staging"
}

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:

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 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.

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

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

                if (it.name == 'testDebugUnitTest') {
                    systemProperty 'debug', 'true'
                }
                ...
            }
        }
    }
}

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:

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

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.