O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Configurar Sharding

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 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 do proprietário do módulo para ajustar 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 de fios que ele não deve ser fragmentado.

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 (instalar 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?

Um teste de instrumentação executado por meio do AndroidJUnitTest não expõe ao arnês 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 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 shards resulta em cinco shards com um teste e um shard sem nenhum teste. 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" /> permitiria ao chicote saber que fragmentar esse módulo não vale a pena.

O AndroidJUnitTest tem uma opção especial que permite especificar o número máximo de fragmentos que pode fragmentar 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 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 garantirá que você não esteja criando fragmentos vazios.