Esta página descreve o que é possível ajustar para um módulo de pacote ( AndroidTest.xml ) por meio de fragmentação e obter o melhor desempenho de velocidade durante a execução contínua no laboratório. Tentaremos descrever as opções de forma genérica com o racional para o uso de cada uma.
Ao executar continuamente um conjunto no laboratório, o conjunto geralmente é fragmentado em vários dispositivos para reduzir o tempo total de conclusão. O chicote normalmente tenta equilibrar o tempo de execução de cada estilhaço para minimizar o tempo de conclusão geral (quando o último estilhaço termina); mas devido à natureza de alguns testes, nem sempre temos introspecção suficiente e precisamos que o proprietário do módulo ajuste algum comportamento.
Fragmentável ou não divisível?
É possível marcar um módulo ( AndroidTest.xml ) com <option name="not-shardable" value="true" /> para notificar o chicote de fios de que ele não deve ser fragmentado.
Em um módulo típico, deixar o chicote fragmentar seu módulo (o comportamento padrão) é a coisa certa a fazer. Mas em alguns casos, você pode querer substituir esse comportamento:
- Quando a configuração do seu módulo é cara:
A fragmentação de um módulo resulta na preparação (instalar APK, arquivo push, etc.) possivelmente executada uma vez por dispositivo envolvido. Se a configuração do seu módulo for longa e cara e não valer a pena ser replicada em comparação com o tempo de execução do teste, você deve marcar seu módulo como não compartilhável.
- Quando o número de testes em seu módulo é baixo:
Fragmentar um módulo resulta em todos os casos de teste possivelmente sendo executados independentemente em diferentes dispositivos. Isso se relaciona com o primeiro ponto; se o número de testes for baixo, você pode acabar com um único teste ou nenhum teste em alguns fragmentos, o que tornaria qualquer etapa de preparação bastante cara. Instalar um APK para um único caso de teste geralmente não vale a pena, por exemplo.
Testes de instrumentação: número máximo de fragmentos?
Um teste de instrumentação executado por meio do AndroidJUnitTest não expõe ao chicote quantos testes fazem parte da instrumentação até que realmente instalemos e executemos o APK. Essas operações são caras e não podem ser executadas em tempo de fragmentação para todos os módulos que fazem parte do conjunto.
O chicote pode fragmentar demais o teste de instrumentação e acabar com alguns fragmentos vazios; fragmentar um teste de instrumentação com cinco testes em seis fragmentos resulta em cinco fragmentos com um teste e um fragmento sem testes. Cada um desses fragmentos exigiria uma instalação cara do APK.
Portanto, quando o número de testes no APK de teste de instrumentação for baixo, marcar o módulo com <option name="not-shardable" value="true" /> permitirá que o chicote saiba que não vale a pena fragmentar esse módulo.
O AndroidJUnitTest tem uma opção especial que permite especificar o número máximo de shards nos quais é permitido shard: <option name="ajur-max-shard" value="5" /> .
Isso permite especificar um número máximo de vezes que a instrumentação pode ser fragmentada, independentemente do número de fragmentos solicitados no nível de invocação. Por padrão, a instrumentação será fragmentada no número de fragmentos solicitados para a invocação.
Por exemplo, se o APK de teste de instrumentação contiver apenas dois casos de teste, mas você ainda quiser fragmentá-lo, ter um valor ajur-max-shard de 2 garantiria que você não estivesse criando fragmentos vazios.