O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Configurar Fragmentação

Esta página descreve o que é possível para sintonizar para um módulo suite ( AndroidTest.xml ) através de sharding e obter o melhor desempenho de velocidade durante a execução contínua no laboratório. Tentaremos descrever as opções de uma maneira genérica com a lógica de uso de cada uma.

Ao executar continuamente um pacote no laboratório, o pacote geralmente é fragmentado em vários dispositivos para reduzir o tempo de conclusão geral. O chicote normalmente tenta equilibrar o tempo de execução de cada shard para minimizar o tempo de conclusão geral (quando o último shard termina); mas, devido à natureza de alguns testes, nem sempre temos introspecção suficiente e precisamos que o proprietário do módulo ajuste alguns comportamentos.

Shardable ou não shardable?

É possível marcar um módulo ( AndroidTest.xml ) com <option name="not-shardable" value="true" /> para notificar o chicote que ele não deve ser fragmentados.

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 (instale APK, arquivo push, etc.), possivelmente executado uma vez por dispositivo envolvido. Se a configuração do seu módulo for longa e cara e não vale 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:

A fragmentação de um módulo resulta em todos os casos de teste, possivelmente executando de forma independente 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?

Uma instrumentação de teste que atravessa AndroidJUnitTest não expõe ao arnês quantos testes são parte da instrumentação até que realmente instalar e executar 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 pacote.

O chicote pode sobrecarregar 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 de APK cara.

Então, quando o número de testes no APK teste instrumentação é baixa, etiquetando o módulo com <option name="not-shardable" value="true" /> permitiria que o arnês de saber sharding esse módulo não vale a pena.

O AndroidJUnitTest corredor tem uma opção especial que lhe permite especificar o número máximo de cacos lhe é permitido caco em: <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 chamada. Por padrão, a instrumentação será fragmentada no número de fragmentos solicitados para a chamada.

Por exemplo, se o seu APK de teste instrumentação contém apenas dois casos de teste, mas você ainda quer caco isso, ter um ajur-max-shard valor de 2 iria garantir que você não está criando cacos vazias.