Esta página descreve o que é possível ajustar para um módulo de conjunto de testes (AndroidTest.xml) usando o particionamento e conseguir 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 um conjunto de testes continuamente no laboratório, ele geralmente é particionado em vários dispositivos para reduzir o tempo total de conclusão. Normalmente, o harness 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 pode ser particionado?
É possível marcar um módulo (AndroidTest.xml) com
<option name="not-shardable" value="true" /> para notificar o harness de que ele
não deve ser particionado.
Em um módulo típico, permitir que o harness particione seu módulo (o comportamento padrão) é a coisa certa a fazer. No entanto, em alguns casos, talvez você queira substituir esse comportamento:
- Quando a configuração do módulo é cara:
O particionamento de um módulo resulta na preparação (instalar o APK, enviar o 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 particionável.
- Quando o número de testes no módulo é baixo:
O particionamento de um módulo resulta em todos os casos de teste que podem ser 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 teste em alguns fragmentos, o que tornaria qualquer etapa de preparação bastante cara. Por exemplo, instalar um APK para um único caso de teste geralmente não vale a pena.
Testes de instrumentação: número máximo de fragmentos?
Um teste de instrumentação executado pelo AndroidJUnitTest não expõe ao harness quantos testes fazem parte da instrumentação até que instalemos e executemos o APK. Essas operações são caras e não podem ser executadas no momento do particionamento para todos os módulos que fazem parte do conjunto de testes.
O harness pode particionar demais o teste de instrumentação e acabar com alguns fragmentos vazios. O particionamento de 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.
Portanto, 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
harness saiba que o particionamento desse módulo não vale a pena.
O executor AndroidJUnitTest tem uma opção especial que permite especificar o
número máximo de fragmentos em que ele pode ser particionado:
<option name="ajur-max-shard" value="5" />.
Isso permite especificar um número máximo de vezes que a instrumentação pode ser particionada, independentemente do número de fragmentos solicitados no nível de invocação. Por padrão, a instrumentação será particionada 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 particioná-lo, ter um valor ajur-max-shard de 2 garante que você não está criando fragmentos vazios.