Quando o corpus de teste é grande ou o tempo de execução é longo, oferecemos a possibilidade de dividir os testes em vários dispositivos: fragmentação.
A fragmentação tem pré-requisitos para que o executor de testes seja compatível com ela.
A maioria dos principais executores de teste já oferece suporte ao sharding, então não é necessário fazer mais nada. Estes já oferecem suporte à fragmentação: testes de instrumentação, testes controlados pelo lado do host e GTest.
Há dois tipos de fragmentação compatíveis com o Tradefed: local e distribuída. Elas compartilham algumas semelhanças. Por isso, esta página descreve as propriedades comuns e as especificidades de cada uma.
Propriedades comuns
As duas formas de fragmentação pressupõem as mesmas propriedades dos executores de teste: os fragmentos precisam ser independentes e determinísticos. A primeira etapa dos dois fragmentos é criar a lista completa e ordenada dos testes e dividi-los em diferentes grupos/fragmentos.
A principal diferença entre as formas de fragmentação é a maneira como elas executam os testes. Confira mais detalhes nas seções abaixo.
Fragmentação local
O sharding local significa que todos os dispositivos envolvidos na execução da invocação fragmentada estão conectados ao mesmo host físico.
Execução
O sharding local aproveita todos os dispositivos conectados ao mesmo host criando um pool de testes que precisam ser executados e fazendo com que cada dispositivo consulte os testes quando estiver livre (ou seja, quando o teste anterior for concluído). Isso resulta em uma utilização otimizada do dispositivo. Também chamamos isso de fragmentação dinâmica.
Opções
--shard-count XX
Fragmentação distribuída
O sharding distribuído significa que todos os dispositivos envolvidos na execução da invocação fragmentada podem estar em qualquer lugar e conectados a diferentes hosts físicos.
Execução
O sharding distribuído ocorre ao criar a lista de testes, e o conteúdo de cada shard executa apenas o shard solicitado no momento. Assim, todos os fragmentos distribuídos criam a mesma lista no início e executam um subconjunto mutuamente exclusivo dela, o que resulta na execução de todos os testes.
A principal propriedade dessa forma é que os fragmentos não têm conhecimento uns dos outros e podem falhar de forma independente.
A principal desvantagem é que o comprimento do fragmento não é necessariamente equilibrado simplesmente porque não podemos prever com antecedência o tempo de execução de cada teste em cada fragmento. A distribuição é feita para ter aproximadamente o mesmo número de casos de teste em cada fragmento.
Opções
--shard-count XX --shard-index XX
Fragmentação de token
O fragmentação de token só pode ser usado com a fragmentação local. A flag não funciona em casos de uso de fragmentação não local. Às vezes, um dos dispositivos envolvidos no sharding tem recursos especiais que outros não têm, como um chip. Alguns testes só funcionam quando esse recurso especial está disponível e falham caso contrário.
O sharding de token é nossa solução para esses casos de uso. Os módulos de teste podem
declarar qual recurso especial eles precisam no AndroidTest.xml, e
o Tradefed encaminha os testes para um dispositivo que tem o recurso.
Configuração de XML
<option name="config-descriptor:metadata" key="token" value="SIM_CARD" />
O value do token corresponde ao
TokenProperty
do Tradefed e está associado a um gerenciador em
TokenProviderHelper.
Isso permite que os módulos de teste sejam executados em dispositivos que podem executar os testes corretamente.
E se nenhum dispositivo puder executar o teste?
Se nenhum dispositivo disponível tiver o recurso correspondente ao módulo de teste, o módulo de teste vai falhar e será ignorado porque não pode ser executado corretamente.
Por exemplo, se um módulo de teste solicitar um chip para ser executado, mas nenhum dispositivo tiver um, o módulo de teste vai falhar.
Implementação
Transmita essa flag de recurso para a linha de comando principal do Tradefed:
--enable-token-sharding