Trace: DeFlaker

DeFlaker

DeFlaker

Principais referências

  • DeFlaker: Automatically Detecting Flaky Tests (10.1145/3180155.3180164).

Descrição

O trabalho descreve e avalia uma ferramenta para a rápida detecção de flaky tests. A técnica baseia-se na análise da cobertura do código comum entre duas iterações de código para classificar um caso de teste falho como um teste flaky. Se o caso de teste falhou, mas a análise de cobertura não indicar que ocorreu a execução de código comum às duas iterações (differential code coverage), o caso de teste é classificado como flaky. Caso tenha ocorrido alguma alteração de código, então o valor da cobertura será diferente de zero e, provavelmente, o erro foi causado por alguma coisa mais “determinística”. No entanto, antes de informar que não é flaky, ainda verifica-se o resultado da execução do caso de teste com a mesma versão do código da aplicação (ao invés de uma versão diferente). Caso falhe, então é a definição clássica de flaky test, então o caso de teste é marcado como tal. Como vantagem, a técnica é superrápida. Porém, a técnica de execução sucessiva _pode_ ser mais eficiente, permitindo-se um custo computacional muito mais elevado e a demora para a classificação do caso de teste como flaky ou não. Além disso, uma desvantagem do DeFlaker é que ele gera falsos positivos quando ele não detecta código executado pelo caso de teste (por causa da instrumentação parcial do código ou alterações não relacionadas ao código fonte, a cobertura pode ser zero porque não foi identificado, pela análise/instrumentação, código sensibilizado pelo caso de teste, sendo a cobertura zero por omissão).

Construção da base de dados (dataset)

A técnica mais utilizada á a reexecução de cada caso de teste faltoso: ReRun. Após reexecutá-lo várias vezes, o resultado de todas as execuções deve ser o mesmo. Caso alguma reexecução seja bem sucedida, o caso de teste é flaky. Caso todas as reexecuções falhem, não é possível definir se o caso de teste é flaky (afinal, se foi submetido a ReRun, é porque ele falhou uma vez ao menos).

A técnica ReRun possui algumas variações. Embora o conceito básico seja a execução múltiplas vezes do mesmo caso de teste, podem ser considerados algumas características do ambiente de execução para melhorar a chance de encontrar casos de teste flaky: * Isolamento da máquina virtual Java (JVM). Por padrão, a reexecução de casos de teste no Maven (por exemplo) ocorre na mesma JVM. Executar cada caso de teste em uma JVM distinta permite resultados melhores. * Reconfiguração do ambiente de construção: limpar os dados gerados por cada execução de caso de teste, provendo um ambiente limpo (reconfigurado) para o ambiente de construção e execução do caso de deteste, também permite resultados melhores.

No artigo que descreve o DeFlaker (10.1145/3180155.3180164), aborda-se também a criação de um conjunto de dados (dataset) que abrange 26 projetos de software livre em Java, considerando as falhas em execução de casos de teste relacionadas a flakyness (5.328) observadas em 5.966 construções (commits/builds) de software. No total, foram considerados 96 casos de teste flaky (manualmente confirmados) e 5.075 confirmados com a estratégia ReRun ++Reboot).

Os 26 projetos consistem de: 4 projetos analisados em tempo real(achilles, checkstyle, jackrabbit-oak, togglz), com 5 casos de teste flaky conhecimentos; 17 projetos descobertos após consulta no Github por termos relacionados a flaky tests (“intermit” ou “flak”), com 81 casos de teste flaky manualmente identificados; e 5 projetos selecionados em trabalho anterior sobre flaky tests (10.1145/2635868.2635920), com 10 casos de teste flaky.

A configuração de execução consistiu de 250 máquinas virtuais Amazon EC2 “c3.large”, cada uma com dois processadores Intel Xeon E5-2680 e 3,75 GiB de RAM. Foram realizadas 47.748 construções de software, utilizando o equivalente a 5 CPU-ano.

Referências

  • Bell, J.; Legunsen, O.; Hilton, M.; Eloussi, L.; Yung, T. and Marinov, D. DeFlaker: Automatically Detecting Flaky Tests. In: 40th International Conference on Software Engineering, ACM, 2018, p. 433–444. DOI: 10.1145/3180155.3180164.
  • Luo, Q., Hariri, F., Eloussi, L. and Marinov, D. An Empirical Analysis of Flaky Tests. 643–653. DOI: 10.1145/2635868.2635920.
work/deflaker.txt · Last modified: 2021/09/14 14:11 by magsilva