Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Configurar Sharding

Esta página describe lo que es posible sintonizar para un módulo de suite ( AndroidTest.xml ) a través de sharding y obtener el mejor rendimiento de velocidad durante la ejecución continua en el laboratorio. Intentaremos describir las opciones de manera genérica con el racional para usar cada una.

Cuando se ejecuta de forma continua una suite en el laboratorio, la suite generalmente se divide en varios dispositivos para reducir el tiempo de finalización general. El arnés generalmente intenta equilibrar el tiempo de ejecución de cada fragmento para minimizar el tiempo total de finalización (cuando finaliza el último fragmento); pero debido a la naturaleza de algunas pruebas, no siempre tenemos suficiente introspección y necesitamos que el propietario del módulo ajuste algún comportamiento.

Shardable o no Shardable?

Es posible etiquetar un módulo ( AndroidTest.xml ) con <option name="not-shardable" value="true" /> para notificar al arnés que no se debe fragmentar.

En un módulo típico, dejar que el arnés fragmente su módulo (el comportamiento predeterminado) es lo correcto. Pero en algunos casos, es posible que desee anular ese comportamiento:

  • Cuando la configuración de su módulo es costosa:

Fragmentar un módulo da como resultado la preparación (instalar APK, archivo push, etc.) posiblemente ejecutada una vez por dispositivo involucrado. Si la configuración de su módulo es larga y costosa y no vale la pena replicarla en comparación con el tiempo de ejecución de la prueba, debe etiquetar su módulo como no fragmentable.

  • Cuando el número de pruebas en su módulo es bajo:

Fragmentar un módulo da como resultado que todos los casos de prueba se ejecuten independientemente en diferentes dispositivos. Esto se relaciona con el primer punto; Si su número de pruebas es bajo, puede terminar con una sola prueba o ninguna en algunos fragmentos, lo que haría que cualquier paso de preparación sea bastante costoso. Instalar un APK para un solo caso de prueba generalmente no vale la pena, por ejemplo.

Pruebas de instrumentación: ¿Número máximo de fragmentos?

Una prueba de instrumentación que se ejecuta a través de AndroidJUnitTest no expone al arnés cuántas pruebas son parte de la instrumentación hasta que realmente instalemos y ejecutemos el APK. Estas operaciones son costosas y no se pueden ejecutar en tiempo de fragmentación para todos los módulos que forman parte de la suite.

El arnés podría sobrepasar la prueba de instrumentación y terminar con algunos fragmentos vacíos; fragmentar una prueba de instrumentación con cinco pruebas en seis fragmentos da como resultado cinco fragmentos con una prueba y un fragmento sin pruebas. Cada uno de estos fragmentos requeriría una instalación costosa de APK.

Entonces, cuando el número de pruebas en el APK de prueba de instrumentación es bajo, etiquetar el módulo con <option name="not-shardable" value="true" /> permitiría que el arnés sepa que ese módulo no vale la pena.

El corredor AndroidJUnitTest tiene una opción especial que le permite especificar el número máximo de fragmentos en los que se le permite fragmentar: <option name="ajur-max-shard" value="5" /> .

Esto le permite especificar un número máximo de veces que la instrumentación se puede fragmentar independientemente de la cantidad de fragmentos solicitados en el nivel de invocación. Por defecto, la instrumentación se dividirá en el número de fragmentos solicitados para la invocación.

Por ejemplo, si su APK de prueba de instrumentación contiene solo dos casos de prueba pero aún desea fragmentarlo, tener un valor ajur-max-shard de 2 aseguraría que no está creando fragmentos vacíos.