Esta página descreve o que é possível ajustar para um módulo de suíte ( 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 maneira genérica com a justificativa para usar cada uma.
Ao executar continuamente um conjunto no laboratório, o conjunto geralmente é fragmentado em vários dispositivos para reduzir o tempo geral de conclusão. O chicote normalmente tenta equilibrar o tempo de execução de cada fragmento para minimizar o tempo geral de conclusão (quando o último fragmento 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 fragmentável?
É possível marcar um módulo ( AndroidTest.xml ) com <option name="not-shardable" value="true" /> para notificar o chicote de que ele não deve ser fragmentado.
Em um módulo típico, permitir que o chicote fragmente 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, enviar arquivo, 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ê deverá marcar seu módulo como não fragmentável.
- Quando o número de testes no seu módulo for baixo:
A fragmentação de um módulo resulta na possibilidade de todos os casos de teste serem executados de forma independente em dispositivos diferentes. Isto está relacionado com o primeiro ponto; se o número de testes for baixo, você poderá 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 equipamento 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 no momento da 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 nenhum teste. 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" /> permitiria que o equipamento soubesse que não vale a pena fragmentar esse módulo.
O executor AndroidJUnitTest tem uma opção especial que permite especificar o número máximo de fragmentos nos quais é permitido fragmentar: <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 seu APK de teste de instrumentação contém apenas dois casos de teste, mas você ainda deseja fragmentá-lo, ter um valor ajur-max-shard de 2 garantiria que você não estivesse criando fragmentos vazios.