O ciclo de vida de um teste executado usando Trade Federation é composto de quatro estágios separados, projetados em torno de interfaces formalmente definidas.
Interfaces definidas
- Provedor de compilação : fornece uma compilação para teste, baixando os arquivos apropriados, se necessário.
- Target Preparer : Prepara o ambiente de teste, possivelmente incluindo instalação de software e configuração de dispositivo.
- Teste : executa teste(s) e coleta resultados de teste. Pode ser qualquer teste JUnit, embora nossa interface IRemoteTest seja projetada especificamente para funcionar bem no ambiente da Trade Federation.
- Ouvinte de invocação de teste (relatório de resultados) : escuta os resultados do teste, geralmente com a finalidade de encaminhar os resultados do teste para um repositório ou exibi-los para o Test Runner.
A entidade de teste fundamental no TF é uma configuração (config). Uma configuração é um arquivo XML que declara os componentes do ciclo de vida de um teste.
Esta separação do ciclo de vida do teste destina-se a permitir a reutilização. Usando este design, o Desenvolvedor pode criar um Teste uma vez, e então o Integrador pode criar diferentes Configurações para executar esse Teste em ambientes diferentes. Por exemplo, eles poderiam criar uma configuração que executará um teste em uma máquina local e despejará o resultado em stdout. Eles poderiam então criar uma segunda configuração que executaria o mesmo teste, mas usaria um Test Invocation Listener diferente para armazenar os resultados do teste em um banco de dados. Uma terceira configuração pode ser projetada para executar esse teste continuamente em um laboratório de teste em algum lugar.
É conveniente observar aqui que um Configuration junto com seus argumentos de linha de comando (conforme fornecidos pelo Test Runner) é conhecido como Command . Quando TF emparelha um Command com um ITestDevice e o executa, o objeto subsequente é conhecido como Invocation . Resumindo, uma Invocação abrange uma execução completa de teste TF, em todo o seu ciclo de vida.
Componentes de configuração adicionais
- Recuperação de Dispositivo : mecanismo para recuperar a comunicação do dispositivo em caso de perda.
- Logger : coleta dados de registro negociados.
Saída e erros do estágio
Cada estágio de uma invocação é executado sequencialmente e tem um objetivo específico. Esta seção descreve as saídas e erros usuais de cada estágio.
Provedor de compilação
Este estágio cria e gera um objeto IBuildInfo que contém todas as referências de arquivos necessárias para configurar e executar os testes.
O erro mais comum nesta fase é a falha ao baixar ou encontrar os arquivos solicitados.
Um erro neste estágio resulta no relato direto do erro e nenhum teste é executado.
Preparação de alvo
Esta etapa configura os estados necessários para o alvo em teste. Este estágio pode alterar a configuração do dispositivo ou do host conforme necessário para uma determinada invocação de teste.
Erros comuns neste estágio geralmente envolvem falha na configuração do dispositivo em um determinado estado (por exemplo, falha na atualização) e falha na localização dos arquivos necessários para a configuração.
Um erro neste estágio resulta na execução da limpeza do alvo, no relatório do erro e na ausência de execução de testes.
Testes
Esta etapa executa os testes solicitados no alvo previamente preparado e reporta todos os resultados da execução do teste.
Erros comuns neste estágio geralmente envolvem a indisponibilidade do alvo em teste ou algum erro que causa a execução parcial dos testes. Esses erros são problemas de infraestrutura que afetam a execução do teste em si, em oposição à falha de um único caso de teste.
Um erro neste estágio resulta na interrupção da execução do teste, na execução da limpeza do alvo, no relato do erro e na obtenção de resultados parciais.
Relatório de resultados
Esta etapa reporta os resultados e erros aos serviços configurados (por exemplo, servidores e arquivos locais).
Embora os relatores de resultados individuais possam ter erros, eles estão isolados uns dos outros (um relator não vê os erros do outro). Esses erros afetam apenas o relatório de resultados de um relator individual e os erros podem ser visualizados nos registros.