Scala i tuoi test con i dispositivi gestiti da Gradle

I dispositivi gestiti da Gradle migliorano coerenza, prestazioni e affidabilità per per eseguire i test con strumentazione automatizzata. Questa funzionalità, disponibile per i livelli API 27 e superiore, consente di configurare dispositivi di test fisici virtuali o remoti dei file Gradle del progetto. Il sistema di compilazione utilizza le configurazioni creare, distribuire e rimuovere questi dispositivi durante l'esecuzione test automatici.

Questa funzionalità garantisce a Gradle la visibilità non solo sui test in esecuzione, ma anche il ciclo di vita dei dispositivi, migliorando così la qualità dei tuoi di test nei seguenti modi:

• Gestisce i problemi relativi al dispositivo per garantire l'esecuzione dei test
• Per i dispositivi virtuali, utilizza gli snapshot dell'emulatore per migliorare i tempi di avvio del dispositivo e l'utilizzo della memoria e di ripristinare i dispositivi a uno stato pulito tra un test e l'altro
• Memorizza nella cache i risultati dei test ed esegue nuovamente solo i test che è probabile che forniscano risultati
• Fornisce un ambiente coerente per l'esecuzione dei test tra ambienti esecuzioni test remoti

Crea un dispositivo virtuale gestito da Gradle

Puoi specificare un dispositivo virtuale che vuoi che Gradle utilizzi per testare il tuo nel file di build a livello di modulo. Il seguente esempio di codice crea un Pixel 2 con il livello API 30 come dispositivo gestito da Gradle.

android {
  testOptions {
    managedDevices {
      localDevices {
        create("pixel2api30") {
          // 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"
        }
      }
    }
  }
}

android {
  testOptions {
    managedDevices {
      localDevices {
        pixel2api30 {
          // 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"
        }
      }
    }
  }
}

Definire 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ù livelli dispositivi e aggiungerli a un gruppo denominato. Gradle può quindi eseguire i test tutti i dispositivi del gruppo in parallelo.

L'esempio seguente mostra due dispositivi aggiunti a un gruppo di dispositivi chiamato phoneAndTablet.

testOptions {
  managedDevices {
    localDevices {
      create("pixel2api29") { ... }
      create("nexus9api30") { ... }
    }
    groups {
      create("phoneAndTablet") {
        targetDevices.add(devices["pixel2api29"])
        targetDevices.add(devices["nexus9api30"])
      }
    }
  }
}

testOptions {
  managedDevices {
    localDevices {
      pixel2api29 { ... }
      nexus9api30 { ... }
    }
    groups {
      phoneAndTablet {
        targetDevices.add(devices.pixel2api29)
        targetDevices.add(devices.nexus9api30)
      }
    }
  }
}

Esegui i test

Per eseguire i test utilizzando i dispositivi gestiti da Gradle che hai configurato, utilizza la . device-name è il nome del dispositivo in cui hai configurato lo script di build Gradle (ad esempio pixel2api30) e BuildVariant è creare la variante dell'app che vuoi testare.

Su Windows:

gradlew device-nameBuildVariantAndroidTest

Su Linux o macOS:

./gradlew device-nameBuildVariantAndroidTest

Per eseguire i test su un gruppo di dispositivi gestiti da Gradle, usa i seguenti comandi.

Su Windows:

gradlew group-nameGroupBuildVariantAndroidTest

Su Linux o macOS:

./gradlew group-nameGroupBuildVariantAndroidTest

L'output di test include un percorso a un file HTML contenente il report di test. Tu puoi anche importare i risultati dei test in Android Studio per ulteriori analisi facendo clic su Esegui > Cronologia dei test nell'IDE.

Abilita il partizionamento orizzontale di test

I dispositivi gestiti da Gradle supportano il partizionamento orizzontale dei test, che ti consente di suddividere il test su una serie di istanze di dispositivi virtuali identiche, chiamate shards, che vengono eseguite in parallelo. L'uso dello sharding dei test può aiutare a ridurre l'esecuzione complessiva del test al costo di risorse di calcolo aggiuntive.

Per impostare il numero di shard da utilizzare in una determinata esecuzione di test, imposta il valore seguenti nel tuo 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 il numero di shard specificato per ogni profilo del dispositivo nell'esecuzione del test. Quindi, per Ad esempio, se hai eseguito il deployment dei test in un gruppo di tre dispositivi e Da numManagedDeviceShards a due, per i dispositivi gestiti da Gradle verrà eseguito il provisioning di un totale di sei dispositivi virtuali per l'esecuzione del test.

Al termine dei test, Gradle restituisce i risultati dei test in un file .proto per ogni shard usato nell'esecuzione del test.

Utilizza dispositivi di test automatici

I dispositivi gestiti da Gradle supportano un tipo di dispositivo emulatore chiamato Automated Dispositivo di test (ATD), ottimizzato per ridurre le risorse di CPU e memoria quando eseguendo i test instrumentati. Gli ATD migliorano le prestazioni di runtime in alcuni modi:

• Rimuovi le app preinstallate che in genere non sono utili per testare la tua app
• Disattiva alcuni servizi in background che in genere non sono utili per testare l'app
• Disattiva rendering hardware

Prima di iniziare, assicurati di aggiorna l'emulatore Android alla versione più recente Google Cloud Storage. Poi specifica un valore "-atd" durante la definizione di un ambiente gestito da Gradle dispositivo nel file di build a livello di modulo, come mostrato di seguito:

android {
  testOptions {
    managedDevices {
      localDevices {
        create("pixel2api30") {
          // 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"
        }
      }
    }
  }
}

android {
  testOptions {
    managedDevices {
      localDevices {
        pixel2api30 {
          // 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 faresti con altri Dispositivi gestiti da Gradle. Per sfruttare ulteriormente i miglioramenti delle prestazioni, puoi anche utilizzare gli ATD con lo partizionamento orizzontale di test per ridurre il numero totale di esecuzione della suite di test.

Quali dati vengono rimossi dalle immagini ATD?

Oltre a operare in modalità headless, gli ATD ottimizzano anche le prestazioni Rimuovere o disattivare app e servizi che in genere non sono necessari testare il codice della tua app. La tabella seguente fornisce una panoramica dei componenti che abbiamo rimosso o disattivato nelle immagini ATD e nelle descrizioni del motivo per cui potrebbero non utile.

Utilizzare i dispositivi Firebase Test Lab

Puoi eseguire i test con strumenti automatici su larga scala in Firebase Test su dispositivi del lab Dispositivi gestiti da Gradle. Test Lab ti consente di eseguire i test contemporaneamente su una un'ampia gamma di dispositivi Android, fisici e virtuali. Questi test vengono eseguiti data center Google remoti. Con il supporto dei dispositivi gestiti da Gradle, la build sistema può gestire completamente l'esecuzione dei test su questi dispositivi Test Lab in base le tue configurazioni.

Inizia

I passaggi seguenti spiegano come iniziare a utilizzare i dispositivi Firebase Test Lab con Dispositivi gestiti da Gradle. Tieni presente che questi passaggi utilizzano gcloud CLI per fornire e credenziali non applicabili a tutti gli ambienti di sviluppo. Per ulteriori informazioni informazioni sul processo di autenticazione da utilizzare per le tue esigenze, vedi Come Credenziali predefinite dell'applicazione funziona.

1. Per creare un progetto Firebase, vai a Console Firebase. Clic Aggiungi progetto e segui le istruzioni sullo schermo per creare un progetto. Ricorda l'ID progetto.

2. Per installare Google Cloud CLI, segui i passaggi all'indirizzo Installa gcloud CLI.

3. Configura il tuo ambiente locale.

   1. Collega il tuo progetto Firebase in gcloud:

      gcloud config set project FIREBASE_PROJECT_ID
      

   2. Autorizza l'utilizzo delle tue credenziali utente per l'accesso all'API. I nostri suggerimenti tramite l'autorizzazione, file JSON dell'account di servizio a Gradle utilizzando DSL nello script di build a livello di modulo:

      Kotlin

      firebaseTestLab {
        ...
        serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE))
      }
      

      Alla moda

      firebaseTestLab {
        ...
        serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE)
      }
      

      In alternativa, puoi autorizzare manualmente utilizzando il seguente terminale :

      gcloud auth application-default login
      

   3. (Facoltativo) Aggiungi il progetto Firebase come progetto di quota. Questo passaggio è necessaria solo se superi il limite quota senza costi aggiuntivi per Test Lab.

      gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
      

4. Abilita le API richieste.

   Nella pagina della libreria API di Google Developers Console, Abilitare l'API Cloud Testing e API Cloud Tool Results digitando i nomi delle API nella casella di ricerca nella parte superiore della console e facendo clic su Abilita API nella pagina Panoramica per ciascuna API.

5. Configura il tuo progetto Android.

   1. Aggiungi il plug-in Firebase Test Lab nello script di build di primo livello:

      Kotlin

      plugins {
        ...
        id("com.google.firebase.testlab") version "0.0.1-alpha05" apply false
      }
      

      Alla moda

      plugins {
        ...
        id 'com.google.firebase.testlab' version '0.0.1-alpha05' apply false
      }
      

   2. Attiva tipi di dispositivi personalizzati nel file gradle.properties:

      android.experimental.testOptions.managedDevices.customDevice=true
      

   3. Aggiungi il plug-in Firebase Test Lab nello script di build a livello di modulo:

      Kotlin

      plugins {
       ...
       id "com.google.firebase.testlab"
      }
      

      Alla moda

      plugins {
       ...
       id 'com.google.firebase.testlab'
      }
      

Specifica un dispositivo Test Lab

Puoi specificare un dispositivo Firebase Test Lab che Gradle può utilizzare per testare il tuo nello script di build a livello di modulo. Il seguente esempio di codice crea un'istanza Pixel 3 con livello API 30, chiamato dispositivo Test Lab gestito da Gradle ftlDevice. Il blocco firebaseTestLab {} è disponibile quando applichi il metodo Plug-in com.google.firebase.testlab al modulo.

firebaseTestLab {
  managedDevices {
    create("ftlDevice") {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

firebaseTestLab {
  managedDevices {
    ftlDevice {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

Per definire un gruppo di dispositivi gestiti da Gradle, inclusi i dispositivi Firebase Test Lab, vedi Definire gruppi di dispositivi.

Per eseguire i test, utilizza gli stessi comandi utilizzati per eseguire altre applicazioni gestite da Gradle dispositivi mobili. Tieni presente che Gradle non esegue test in parallelo né supporta altre configurazioni di Google Cloud CLI per i dispositivi Test Lab.

Ottimizza le esecuzioni dei test con il partizionamento orizzontale intelligente

I test su dispositivi Test Lab gestiti da Gradle supportano lo sharding intelligente. Intelligente Lo sharding distribuisce automaticamente i test tra gli shard, in modo che ogni viene eseguito all'incirca contemporaneamente, riducendo le attività di allocazione manuale durata complessiva dell'esecuzione del test. Lo sharding intelligente utilizza le informazioni o la cronologia dei test sul tempo necessario per eseguire i test in precedenza, per distribuire i test in modo ottimale. Tieni presente che è necessaria la versione 0.0.1-alpha05 del plug-in Gradle affinché Firebase Test Lab utilizzi lo sharding intelligente.

Per abilitare lo sharding intelligente, specifica il periodo di tempo in cui eseguire i test all'interno di ogni shard prendere. Devi impostare la durata del tempo shard target su almeno cinque minuti meno di timeoutMinutes per evitare la situazione in cui gli shard annullato prima del termine dei test.

firebaseTestLab {
  ...
  testOptions {
    targetedShardDurationMinutes = 2
  }
}

Per saperne di più, leggi le informazioni Opzioni DSL per i dispositivi di Firebase Test Lab.

DSL aggiornato per i dispositivi Test Lab

Esistono altre opzioni DSL che puoi configurare per personalizzare le esecuzioni dei test eseguire la migrazione da altre soluzioni che potresti già utilizzare. Guarda alcune di queste opzioni come descritto nello snippet di codice riportato di seguito.

firebaseTestLab {
  ...

  /**
   * A path to a JSON file that contains service account credentials to access to
   * a Firebase Test Lab project.
   */
  serviceAccountCredentials.set(file("your_service_account_credentials.json"))


  testOptions {
    fixture {
      /**
       * Whether to grant permissions on the device before tests begin.
       * Available options are "all" or "none".
       *
       * Default value is "all".
       */
      grantedPermissions = "all"

      /**
       * Map of files to push to the device before starting the test.
       *
       * The key is the location on the device.
       * The value is the location of the file, either local or in Google Cloud.
       */
      extraDeviceFiles["/sdcard/dir1/file1.txt"] = "local/file.txt"
      extraDeviceFiles["/sdcard/dir2/file2.txt"] = "gs://bucket/file.jpg"

      /**
       * The name of the network traffic profile.
       *
       * Specifies network conditions to emulate when running tests.
       *
       * Default value is empty.
       */
      networkProfile = "LTE"
    }

    execution {
      /**
       * The maximum time to run the test execution before cancellation,
       * measured in minutes. Does not include the setup or teardown of device,
       * and is handled server-side.
       *
       * The maximum possible testing time is 45 minutes on physical devices
       * and 60 minutes on virtual devices.
       *
       * Defaults to 15 minutes.
       */
       timeoutMinutes = 30

      /**
       * Number of times the test should be rerun if tests fail.
       * The number of times a test execution should be retried if one
       * or more of its test cases fail.
       *
       * The max number of times is 10.
       *
       * The default number of times is 0.
       */
      maxTestReruns = 2

      /**
       * Ensures only a single attempt is made for each execution if
       * an infrastructure issue occurs. This doesn't affect `maxTestReruns`.
       * Normally, two or more attempts are made by Firebase Test Lab if a
       * potential infrastructure issue is detected. This is best enabled for
       * latency sensitive workloads. The number of execution failures might be
       * significantly greater with `failFast` enabled.
       *
       * Defaults to false.
       */
      failFast = false

      /**
       * The number of shards to split the tests across.
       *
       * Default to 0 for no sharding.
       */
      numUniformShards = 20
    }

    /**
     * For smart sharding, the target length of time each shard should takes in
     * minutes. Maxes out at 50 shards for physical devices and 100 shards for
     * virtual devices.
     *
     * Only one of numUniformShards or targetedShardDurationMinutes can be set.
     *
     * Defaults to 0 for no smart sharding.
     */
     targetedShardDurationMinutes = 15
    }

    results {
      /**
       * The name of the Google storage bucket to store the test results in.
       *
       * If left unspecified, the default bucket is used.
       *
       * Please refer to Firebase Test Lab permissions for required permissions
       * for using the bucket.
       */
      cloudStorageBucket = "bucketLocationName"

      /**
       * Name of test results for the Firebase console history list.
       * All tests results with the same history name are grouped
       * together in the Firebase console in a time-ordered test history list.
       *
       * Defaults to the application label in the APK manifest in Flank/Fladle.
       */
      resultsHistoryName = "application-history"

      /**
       * List of paths to copy from the test device's storage to the test
       * results folder. These must be absolute paths under /sdcard or
       * /data/local/tmp.
       */
      directoriesToPull.addAll(
        "/sdcard/path/to/something"
      )

      /**
       * Whether to enable video recording during the test.
       *
       * Disabled by default.
       */
      recordVideo = false

      /**
       * Whether to enable performance metrics. If enabled, monitors and records
       * performance metrics such as CPU, memory, and network usage.
       *
       * Defaults to false.
       */
      performanceMetrics = true
  }
}