Esta página descreve o que é possível ajustar para um módulo de pacote
(AndroidTest.xml) usando o fragmentação e conseguir a melhor velocidade de execução contínua no laboratório. Vamos tentar descrever as opções de maneira
genérica com a justificativa para usar cada uma delas.
Ao executar continuamente um pacote no laboratório, ele geralmente é dividido em vários dispositivos para reduzir o tempo de conclusão geral. O arcabouço normalmente 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 ser fragmentado ou não?
É 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 dividido.
Em um módulo comum, permitir a fragmentação de arcabouço do módulo (o comportamento padrão) é a coisa certa a fazer. Mas, em alguns casos, é possível modificar esse comportamento:
- Quando a configuração do módulo é cara:
A fragmentação de um módulo resulta na preparação (APK de instalação, arquivo push etc.) possivelmente 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 estiver baixo:
O fragmentação de um módulo resulta em todos os casos de teste possivelmente sendo executados de forma independente em diferentes dispositivos. Isso está relacionado 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 muito 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 pelo AndroidJUnitTest não expõe ao harness 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 sharding para todos os módulos do pacote.
O arcabouço pode fragmentar em excesso o teste de instrumentação e acabar com alguns fragmentos vazios. A fragmentação de um teste de instrumentação com cinco testes em seis fragmentos resulta em cinco fragmentos com um teste e um 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, a inclusão de tags no
módulo com <option name="not-shardable" value="true" /> permite que o
harness saiba que o sharding 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 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, independentemente do número de fragmentos solicitados no nível de invocação. Por padrão, a instrumentação será dividida no número de fragmentos solicitados para a invocação.
Por exemplo, se o APK do teste de instrumentação tiver apenas dois casos de teste, mas
você ainda quiser particioná-lo, ter um valor de ajur-max-shard de 2 garantirá
que você não está criando fragmentos vazios.