Criar um executor de testes do Tradefed

Esta página descreve como criar um novo executor de testes no Tradefed.

Contexto

Se você quiser saber mais sobre os executores de testes na arquitetura do Tradefed, consulte Estrutura de um executor de testes.

Isso não é um pré-requisito para programar um novo executor de testes. os executores de testes podem ser escritas isoladamente.

Mínimo básico: implementar a interface

O mínimo para se qualificar como executor de testes do Tradefed é implementar a Interface IRemoteTest (link em inglês) e, mais especificamente, o método run(TestInformation testInfo, ITestInvocationListener listener).

Esse método é o invocado pelo arcabouço ao usar o executor de testes, semelhante a um executável em Java.

Cada parte desse método é considerada parte da execução do executor de testes.

Informar os resultados do executor de testes

O método run na interface base dá acesso a um objeto listener de digite ITestInvocationListener. Esse objeto é a chave para gerar relatórios estruturados do executor de testes para o arcabouço.

Ao relatar resultados estruturados, um executor de testes tem as seguintes propriedades:

  • Informar uma lista adequada de todos os testes realizados, quanto tempo eles levaram e se eles passaram, falharam ou alguns outros estados.
  • Métricas de relatórios associadas aos testes, se aplicável, por exemplo métricas de tempo de instalação.
  • se encaixam na maioria das ferramentas de infraestrutura. Por exemplo, exibir resultados e métricas etc.
  • Geralmente mais fácil de depurar, porque há um rastro mais granular do execução.

Dito isso, informar resultados estruturados é opcional. um executor de testes pode simplesmente avaliar o estado de toda a execução como PASSED ou FAILED sem todos os detalhes da execução real.

Os eventos a seguir podem ser chamados no listener para notificar o arcabouço do Progresso atual das execuções:

  • testRunStarted: notifica o início de um grupo de casos de teste que estão relacionados.
    • testStarted: notifica o início do início de um caso de teste.
    • testFailed/testIgnored: notifica a alteração de estado do caso de teste. em andamento. Um caso de teste sem qualquer mudança de estado é considerado passou.
    • testEnded: notifica o final do caso de teste.
  • testRunFailed: informa que o status geral do grupo de casos de teste. a execução seja uma falha. Uma execução de teste pode ser uma aprovação ou uma reprovação. de forma independente dos resultados dos casos de teste, dependendo do que que a execução esperava. Por exemplo, um binário que executa vários casos de teste poderia relatar todos os casos de teste aprovados, mas com um código de saída de erro (para qualquer motivos: arquivos vazados etc.).
  • testRunEnded: notifica o final do grupo de casos de teste.

Manter e garantir a ordem correta dos callbacks é o responsabilidade do implementador do executor de testes, por exemplo, garantir que testRunEnded é chamado em caso de exceção usando uma cláusula finally.

Os callbacks de casos de teste (testStarted, testEnded etc.) são opcionais. Um teste pode ocorrer sem nenhum caso de teste.

Você pode notar que essa estrutura de eventos é inspirada estrutura JUnit típica. O propósito disso é manter as coisas próximas ao básico que os desenvolvedores que você normalmente tem conhecimento.

Registros de relatórios do executor de testes

Se estiver criando sua própria classe de teste ou executor do Tradefed, você implementará IRemoteTest (link em inglês) e receber um ITestInvocationListener com o método run(). Este listener pode ser usada para registrar arquivos da seguinte forma:

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

Testar com um dispositivo

A interface mínima acima permite executar testes muito simples que são isolados e não exigem recursos específicos, como testes de unidade do Java.

Os redatores de teste que quiserem passar para a próxima etapa dos testes de dispositivos precisarão das seguintes interfaces:

  • IDeviceTest (link em inglês) permite receber o objeto ITestDevice que representa o dispositivo em e fornece a API para interagir com ele.
  • IBuildReceiver (em inglês) permite que o teste acesse o objeto IBuildInfo criado no etapa do provedor de build que contêm todas as informações e artefatos relacionados à configuração do teste.

Geralmente, os executores de testes se interessam por essas interfaces para artefatos relacionados à execução, como arquivos extras, e dispositivo em teste que será segmentado durante a execução.

Testar com vários dispositivos

O Tradefed oferece suporte à execução de testes em vários dispositivos ao mesmo tempo. Isso é útil ao testar componentes que exigem uma interação externa, como um celular e relógio.

Para programar um executor de testes que possa usar vários dispositivos, você precisará para implementar IMultiDeviceTest (link em inglês), que permite receber um mapa de ITestDevice para IBuildInfo que contenha a lista completa de representações de dispositivos e as informações de versão associadas a elas.

O setter da interface sempre vai ser chamado antes do método run. Portanto, é seguro presumir que a estrutura estará disponível quando run for chamado.

Testes cientes das próprias configurações

Algumas implementações do executor de testes podem precisar de informações sobre a configuração geral para funcionar corretamente, por exemplo, alguns metadados sobre a invocação ou quais target_preparer já foram executados antes etc.

Para fazer isso, um executor de testes pode acessar o objeto IConfiguration. do qual faz parte e na qual é executado. Consulte a objeto de configuração para mais detalhes.

Para a implementação do executor de testes, será necessário implementar a propriedade IConfigurationReceiver (em inglês) para receber o objeto IConfiguration.

Executor de testes flexível

Os executores de testes podem oferecer uma maneira flexível de executar os testes se tiverem um controle granular sobre eles. Por exemplo, um executor de testes JUnit pode realizar executar cada teste de unidade.

Isso permite que o arcabouço e a infraestrutura maiores aproveitem esse controle refinado e os usuários executarem parcialmente o executor de testes por meio de filtragem.

O suporte à filtragem é descrito nas Interface ITestFilterReceiver, que permite receber conjuntos de filtros include e exclude para os testes. que deve ou não ser executado.

Nossa convenção é que um teste seja executado IFF que corresponde a um ou mais dos incluir filtros E não corresponder a nenhum dos filtros de exclusão. Se não forem incluídos são fornecidos, todos os testes devem ser executados, desde que não correspondam a nenhum os filtros de exclusão.