Esta página descreve o que é possível ajustar para um módulo de conjunto
(AndroidTest.xml) usando fragmentação e ter o melhor desempenho de velocidade durante a
execução contínua no laboratório. Vamos tentar descrever as opções de maneira genérica com a lógica para usar cada uma delas.
Ao executar continuamente um conjunto no laboratório, ele geralmente é fragmentado em vários dispositivos para reduzir o tempo total de conclusão. Normalmente, o arnês tenta equilibrar o tempo de execução de cada fragmento para minimizar o tempo total de conclusão (quando o último fragmento termina). No entanto, devido à natureza de alguns testes, nem sempre temos introspecção suficiente e precisamos que o proprietário do módulo ajuste algum comportamento.
Pode ou não ser fragmentado?
É possível adicionar uma tag a um módulo (AndroidTest.xml) com
<option name="not-shardable" value="true" /> para notificar o harness de que ele
não deve ser fragmentado.
Em um módulo típico, deixar o arnés fragmentar seu módulo (o comportamento padrão) é a coisa certa a fazer. Mas, em alguns casos, talvez você queira substituir esse comportamento:
- Quando a configuração do módulo é cara:
O fragmento de um módulo resulta na preparação (instalar APK, enviar arquivo etc.) que pode ser executada uma vez por dispositivo envolvido. Se a configuração do 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, marque o módulo como não fragmentável.
- Quando o número de testes no seu módulo é baixo:
O fragmentação de um módulo faz com que todos os casos de teste sejam executados de forma independente em dispositivos diferentes. Isso se relaciona ao primeiro ponto: se o número de testes for baixo, você poderá acabar com um único teste ou nenhum em alguns fragmentos, o que tornaria qualquer etapa de preparação bastante cara. Por exemplo, não vale a pena instalar um APK para um único caso de teste.
Testes de instrumentação: número máximo de fragmentos?
Um teste de instrumentação executado pelo AndroidJUnitTest não expõe ao ambiente de teste quantos testes fazem parte da instrumentação até que o APK seja instalado e executado. Essas operações são caras e não podem ser executadas no momento do fragmentação para todos os módulos que fazem parte do pacote.
O arnês 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 de APK cara.
Assim, quando o número de testes no APK de teste de instrumentação é baixo, marcar o
módulo com <option name="not-shardable" value="true" /> permite que o
arnês saiba 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 em que ele pode ser dividido:
<option name="ajur-max-shard" value="5" />.
Isso permite especificar um número máximo de vezes que a instrumentação pode ser fragmentada, independente do número de fragmentos solicitados no nível de invocação. Por padrão, a instrumentação é dividida no número de fragmentos solicitado para a invocação.
Por exemplo, se o APK de teste de instrumentação tiver apenas dois casos de teste, mas você ainda quiser fragmentá-lo, um valor ajur-max-shard de 2 vai garantir que você não crie fragmentos vazios.