I dispositivi gestiti da Gradle migliorano coerenza, prestazioni e affidabilità per i tuoi test strumentati automatizzati. Questa funzionalità, disponibile per i livelli API 27 e successivi, consente di configurare dispositivi di test virtuali nei file Gradle del tuo progetto. Il sistema di build utilizza le configurazioni per gestire completamente (ovvero creare, eseguire il deployment ed eliminare) i dispositivi durante l'esecuzione dei test automatici.
Questa funzionalità garantisce a Gradle visibilità non solo sui test in esecuzione, ma anche sul ciclo di vita dei dispositivi, migliorando così la qualità della tua esperienza di test nei seguenti modi:
- Gestisce i problemi relativi ai dispositivi per garantire l'esecuzione dei test
- Utilizza snapshot dell'emulatore per migliorare il tempo di avvio del dispositivo e l'utilizzo della memoria, nonché per ripristinare lo stato pulito dei dispositivi tra un test e l'altro
- Memorizza nella cache i risultati dei test ed esegue nuovamente solo i test che hanno maggiori probabilità di fornire risultati diversi
- Fornisce un ambiente coerente per l'esecuzione dei test tra esecuzioni di test locali e remoti
Inoltre, i dispositivi gestiti da Gradle introducono un nuovo tipo di dispositivo emulatore, denominato ATD (Automated Test Device), ottimizzato per migliorare le prestazioni durante l'esecuzione dei test strumentati. Combinato con il supporto per lo spartizionamento dei test, puoi sperimentare la suddivisione della suite di test in più istanze ATD per ridurre il tempo complessivo di esecuzione del test.
Creare un dispositivo gestito da Gradle
Puoi specificare un dispositivo virtuale che vuoi che Gradle utilizzi per testare la tua app nel file build.gradle a livello di modulo. L'esempio di codice seguente crea un Pixel 2 con livello API 30 come dispositivo gestito da Gradle.
trendy
android {
testOptions {
managedDevices {
devices {
pixel2api30 (com.android.build.api.dsl.ManagedVirtualDevice) {
// Use device profiles you typically see in Android Studio.
device = "Pixel 2"
// Use only API levels 27 and higher.
apiLevel = 30
// To include Google services, use "google".
systemImageSource = "aosp"
}
}
}
}
}
Kotlin
android {
testOptions {
managedDevices {
devices {
maybeCreate<com.android.build.api.dsl.ManagedVirtualDevice>("pixel2api30").apply {
// Use device profiles you typically see in Android Studio.
device = "Pixel 2"
// Use only API levels 27 and higher.
apiLevel = 30
// To include Google services, use "google".
systemImageSource = "aosp"
}
}
}
}
}
Per eseguire i test utilizzando i dispositivi gestiti da Gradle che hai configurato, utilizza il seguente comando. device-name è il nome del dispositivo configurato nello
script di build Gradle (ad esempio pixel2api30) e BuildVariant è
la variante di build dell'app che vuoi testare.
gradlew device-nameBuildVariantAndroidTest
Definisci gruppi di dispositivi
Per aiutarti a scalare i test su più configurazioni di dispositivi, ad esempio diversi livelli API e fattori di forma, puoi definire più dispositivi gestiti da Gradle e aggiungerli a un gruppo denominato. Gradle può quindi eseguire i tuoi test in parallelo su tutti i dispositivi del gruppo.
L'esempio seguente mostra due dispositivi gestiti aggiunti a un gruppo di dispositivi denominato phoneAndTablet.
trendy
testOptions {
managedDevices {
devices {
pixel2api29 (com.android.build.api.dsl.ManagedVirtualDevice) { ... }
nexus9api30 (com.android.build.api.dsl.ManagedVirtualDevice) { ... }
}
groups {
phoneAndTablet {
targetDevices.add(devices.pixel2api29)
targetDevices.add(devices.nexus9api30)
}
}
}
}
Kotlin
testOptions {
managedDevices {
devices {
maybeCreate<com.android.build.api.dsl.ManagedVirtualDevice>("pixel2api29").apply { ... }
maybeCreate<com.android.build.api.dsl.ManagedVirtualDevice>("nexus9api30").apply { ... }
}
groups {
maybeCreate("phoneAndTablet").apply {
targetDevices.add(devices["pixel2api29"])
targetDevices.add(devices["nexus9api30"])
}
}
}
}
Per eseguire i test utilizzando il gruppo di dispositivi gestiti da Gradle, utilizza il seguente comando:
gradlew group-nameGroupBuildVariantAndroidTest
Eseguire test utilizzando dispositivi di test automatici
Gradle Managed Devices supporta un nuovo tipo di dispositivo emulatore, denominato ATD (Automated Test Device), ottimizzato per ridurre le risorse di CPU e memoria durante l'esecuzione dei test strumentati. Gli ATD migliorano le prestazioni del runtime in diversi modi:
- Rimuovi le app preinstallate che in genere non sono utili per testare l'app
- Disattiva determinati servizi in background che in genere non sono utili per testare la tua app
- Disattiva rendering hardware
Prima di iniziare, assicurati di aggiornare Android Emulator all'ultima versione disponibile. Quindi, specifica un'immagine "-atd" quando definisci un dispositivo gestito da Gradle in build.gradle, come mostrato di seguito:
trendy
android {
testOptions {
managedDevices {
devices {
pixel2api30 (com.android.build.api.dsl.ManagedVirtualDevice) {
// Use device profiles you typically see in Android Studio.
device = "Pixel 2"
// ATDs currently support only API level 30.
apiLevel = 30
// You can also specify "google-atd" if you require Google Play Services.
systemImageSource = "aosp-atd"
}
}
}
}
}
Kotlin
android {
testOptions {
managedDevices {
devices {
maybeCreate<com.android.build.api.dsl.ManagedVirtualDevice>("pixel2api30").apply {
// Use device profiles you typically see in Android Studio.
device = "Pixel 2"
// ATDs currently support only API level 30.
apiLevel = 30
// You can also specify "google-atd" if you require Google Play Services.
systemImageSource = "aosp-atd"
}
}
}
}
}
Puoi anche creare gruppi di dispositivi come con altri dispositivi gestiti da Gradle. Per sfruttare ulteriormente i miglioramenti delle prestazioni, puoi anche utilizzare gli ATD con partizionamento orizzontale di test per ridurre il tempo totale di esecuzione del test della tua suite di test.
Che cosa viene rimosso dalle immagini ATD?
Oltre a funzionare in modalità headless, gli ATD ottimizzano anche le prestazioni rimuovendo o disattivando app e servizi che in genere non sono necessari per testare il codice dell'app. La tabella riportata di seguito fornisce una panoramica dei componenti che abbiamo rimosso o disattivato nelle immagini ATD, oltre alle descrizioni del motivo per cui potrebbero non essere utili.
| Che cosa viene rimosso nelle immagini ATD | Perché potrebbe non essere necessario durante l'esecuzione di test automatici |
|---|---|
App dei prodotti Google:
|
I test automatici dovrebbero concentrarsi sulla logica della tua app, supponendo che altre app o la piattaforma funzionino correttamente.
Con Espresso-Intents, puoi associare e convalidare i tuoi intent in uscita o persino fornire risposte stub al posto di quelle effettive. |
App e servizi per le impostazioni:
|
Queste app presentano una GUI che consente agli utenti finali di modificare le impostazioni della piattaforma, configurare il dispositivo o gestire lo spazio di archiviazione del dispositivo. In genere questo non rientra nell'ambito dei test automatici a livello di app.
|
| SystemUI | I test automatici dovrebbero concentrarsi sulla logica della tua app, supponendo che altre app o la piattaforma funzionino correttamente. |
App e servizi AOSP:
|
In genere queste app e questi servizi non rientrano nell'ambito dei test automatici per il codice della tua app. |
Abilita lo sharding di test
I dispositivi gestiti da Gradle supportano lo sharding di test, che consente di suddividere la suite di test tra una serie di istanze di dispositivi virtuali identiche, chiamate shard, che vengono eseguite in parallelo. L'utilizzo dello sharding del test può contribuire a ridurre i tempi di esecuzione del test complessivi a costo di risorse di calcolo aggiuntive.
Per impostare il numero di shard da utilizzare in una determinata esecuzione di test, imposta quanto segue nel file gradle.properties:
android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>
Quando esegui i test utilizzando questa opzione, i dispositivi gestiti da Gradle eseguono il provisioning del numero di shard specificato per ogni profilo del dispositivo nell'esecuzione del test. Ad esempio, se hai eseguito il deployment dei test su un gruppo di dispositivi di tre dispositivi e hai impostato numManagedDeviceShards su due, i dispositivi gestiti da Gradle eseguiranno il provisioning di un totale di sei dispositivi virtuali per l'esecuzione del test.
Al termine dei test, Gradle restituisce i risultati del test in un file .proto per ogni shard utilizzato nell'esecuzione del test.