Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Configurar fragmentación

Esta página describe lo que es posible ajustar para un módulo de la suite ( AndroidTest.xml ) mediante fragmentación 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" /> para notificar al arnés que no debe ser fragmentado.

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:

Al fragmentar un módulo, la preparación (instalar APK, archivo de inserción, etc.) posiblemente se ejecute 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 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 instalamos y ejecutamos 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 fragmentar demasiado 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 lo tanto, 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 al arnés saber que la fragmentación de ese módulo no vale la pena.

El AndroidJUnitTest tiene una opción especial que le permite especificar el número máximo de fragmentos en los que se permite fragmentar: <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 la cantidad 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 garantizaría que no esté creando fragmentos vacíos.