Flaky tests 📖 Wikipedia

O teste de regressão é uma atividade de verificação e validação de sistemas presente na engenharia de software moderna.^[1] Ele é responsável por garantir que as funcionalidades de um software não sejam danificadas com futuras atualizações, garantindo o comportamento esperado na especificação do produto. Espera-se que o valor do teste seja mantido se o código-fonte não for alterado. Porém, ele pode variar (e.g. de falso para verdadeiro e vice-versa) em diferentes execuções sem alterações no código. Este evento caracteriza o teste como flaky ou instável.

Considerando que instabilidades em testes são inevitáveis, no Facebook propuseram a seguinte abordagem: assumir que todos os testes possuem seu grau de instabilidade é mais seguro para que o desenvolvedor tenha maior atenção durante sua implementação e também reconheça os padrões de instabilidade em cada cenário de teste. Essa abordagem chama-se ATAF.^[2]

As fases de testes mais comuns são: testes de unidade, testes de integração e testes de sistema (e.g. interface do usuário). Os testes de unidade geralmente são mais rápidos e testam funcionalidades de maneira isolada. Já os testes end-to-end e GUI podem ser mais lentos e necessitam de maior interação entre componentes e serviços. Existe a hipótese de que testes end-to-end e UI possuem custo mais elevado, principalmente quando aplicadas técnicas de re-execução para identificar flaky tests. Nesse cenário, tornar-se-ia mais relevante a utilização de técnicas mais rápidas, como aqueles que consideram o vocabulário de casos de teste flaky.

Em GUI os casos de teste são sequências de eventos, em vez de entradas simples. O resultado a ser testado pode ser um estado esperado para aplicação após a sequência de eventos, ou certa interface esperada. Isto possibilita a simulação de ações que são realizadas na interface em uma ordem específica. O estado atual da interface depende da entrada de eventos e da execução de funções assíncronas. Neste cenário, a instabilidade pode ocorrer por dois motivos: ordem incorreta de eventos ou atraso na execução de funções de callback que retornam dados para interface. Existem fatores associados ao flakiness, são eles: versão da linguagem (e.g. Java), sistema operacional, carga do sistema, ordem de execução, threads de cálculos, atrasos de retorno de dados. Todos esses elementos podem variar de certa maneira inesperada, ocasionando um flaky test.^[3]

A instabilidade na maioria das vezes é resultado da dificuldade de se manter cenários de testes idênticos durante múltiplas execuções, revelando um grau de flakiness em todos tipos de testes.^[4] Em testes GUI e end-to-end é difícil garantir que a disponibilidade da rede se mantenha, que as plataformas de execução sejam idênticas, e que os fatores ambientais envolvidos não interfiram no processo de teste. Este cenário é fértil para instabilidade relacionada a assincronicidade, diferença de plataformas e renderização de recursos.^[5]