Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Configurar fragmentación

Esta página describe lo que es posible sintonizar para un módulo de baño ( 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 la racionalidad para usar cada una.

Cuando se ejecuta continuamente una suite en el laboratorio, la suite generalmente se comparte en varios dispositivos para reducir el tiempo total de finalización. El arnés normalmente intenta equilibrar el tiempo de ejecución de cada fragmento para minimizar el tiempo de finalización general (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" /> notificar al arnés que no debe ser fragmentados.

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:

La fragmentación de un módulo da como resultado que la preparación (instalar APK, archivo de inserción, etc.) se ejecute posiblemente 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 compartible.

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

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

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

Una prueba de funcionamiento a través de la instrumentación AndroidJUnitTest no expone al arnés cuántas pruebas son parte de la instrumentación hasta que realmente instalar y ejecutar el archivo 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 fragmentar en exceso 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 costosa instalación de APK.

Por eso, cuando el número de pruebas en el APK instrumentación de prueba es baja, etiquetado con el módulo <option name="not-shardable" value="true" /> permitiría que el arnés para saber sharding ese módulo no vale la pena.

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

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

Por ejemplo, si el archivo APK instrumentación de prueba contiene sólo dos casos de prueba, pero que todavía quieren fragmentar que, teniendo un ajur-max-shard valor de 2 aseguraría que no está creando fragmentos vacíos.