Quando o corpus de teste é grande ou o tempo de execução se torna 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 ofereça suporte à fragmentação.
A maioria dos executores de teste principais já oferece suporte a fragmentação, então nenhum trabalho extra é necessário. Eles já oferecem suporte à fragmentação: testes de instrumentação, testes orientados pelo host e GTest.
Há dois tipos de fragmentação com suporte no Tradefed: local e distribuído. Elas têm algumas semelhanças, então esta página descreve as propriedades comuns e, em seguida, as especificidades de cada uma delas.
Propriedades comuns
As duas formas de fragmentação pressupõem as mesmas propriedades dos executores de testes: os fragmentos precisam ser independentes e determinísticos. A primeira etapa de ambos os particionamentos é criar a lista ordenada completa dos testes e dividi-los em grupos/fragmentos diferentes.
A principal diferença entre os formatos de fragmentação é a maneira como eles executam os testes. Mais detalhes nas seções abaixo.
Fragmentação local
Fragmentação 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 teste de sondagem do dispositivo seja executado quando estiver disponível (ou seja, concluído com o teste anterior). 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
Sharding distribuído significa que todos os dispositivos envolvidos na execução da invocação fragmentada podem estar em qualquer lugar e ser 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. Portanto, todos os fragmentos distribuídos criam a mesma lista inicialmente e, em seguida, executam um subconjunto mutuamente exclusivo dela, o que resulta na execução de todos os testes.
A propriedade principal desse formulário é que os fragmentos não têm conhecimento total 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 fragmento de token só pode ser usado com o fragmento local. A sinalização não opera em casos de uso de fragmentação não locais. Às vezes, um dos dispositivos envolvidos na fragmentação tem recursos especiais que outros não, como um chip. Alguns testes só funcionam quando esse recurso especial está disponível e falham de outra forma.
O sharding de token é a 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 a execução de um chip, mas nenhum dispositivo tiver um chip, 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