En esta página, se describe lo que se puede ajustar para un módulo de conjunto de pruebas (AndroidTest.xml) a través del fragmentado y cómo obtener el mejor rendimiento de velocidad durante la ejecución continua en el lab. Intentaremos describir las opciones de manera genérica y explicar los motivos para usar cada una.
Cuando se ejecuta de forma continua un conjunto de pruebas en el lab, este suele fragmentarse en varios dispositivos para reducir el tiempo total de finalización. Por lo general, el arnés 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.
¿Se puede fragmentar o no?
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 divida tu módulo (el comportamiento predeterminado) es lo correcto. Sin embargo, en algunos casos, es posible que desees anular ese comportamiento:
- Cuando la configuración de tu módulo es costosa:
La fragmentación de un módulo hace que la preparación (instalación del APK, envío de archivos, etcétera) se ejecute posiblemente una vez por cada dispositivo involucrado. Si la configuración de tu módulo es larga y costosa, y no vale la pena replicarla en comparación con el tiempo de ejecución de la prueba, debes etiquetar tu módulo como no fragmentable.
- Cuando la cantidad de pruebas en tu módulo es baja, haz lo siguiente:
Fragmentar un módulo hace que todos los casos de prueba se puedan ejecutar de forma independiente en diferentes dispositivos. Esto se relaciona con el primer punto: si la cantidad de pruebas es baja, es posible que termines con una sola prueba o ninguna en algunos fragmentos, lo que haría que cualquier paso de preparación sea bastante costoso. Por ejemplo, no suele valer la pena instalar un APK para un solo caso de prueba.
Pruebas de instrumentación: ¿Cuál es la cantidad máxima de fragmentos?
Una prueba de instrumentación que se ejecuta a través de AndroidJUnitTest no expone al arnés cuántas pruebas forman parte de la instrumentación hasta que instalamos y ejecutamos el APK. Estas operaciones son costosas y no se pueden ejecutar en el momento del sharding para todos los módulos que forman parte del paquete.
Es posible que el arnés fragmente en exceso la prueba de instrumentación y termine con algunos fragmentos vacíos. Fragmentar una prueba de instrumentación con cinco pruebas en seis fragmentos genera 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 la cantidad de pruebas en el APK de prueba de instrumentación es baja, etiquetar el módulo con <option name="not-shardable" value="true" /> permitiría que el arnés sepa que no vale la pena fragmentar ese módulo.
El ejecutor AndroidJUnitTest tiene una opción especial que le permite especificar la cantidad máxima de fragmentos en los que se puede fragmentar: <option name="ajur-max-shard" value="5" />.
Esto te permite especificar la cantidad máxima de veces que se puede fragmentar la instrumentación, independientemente de la cantidad de fragmentos solicitados a nivel de la invocación. De forma predeterminada, la instrumentación se fragmentará en la cantidad de fragmentos solicitados para la invocación.
Por ejemplo, si tu APK de prueba de instrumentación solo contiene dos casos de prueba, pero aun así deseas fragmentarlo, tener un valor de ajur-max-shard de 2 garantizaría que no crees fragmentos vacíos.