Vamos começar este artigo com as dúvidas que aparecem sobre o teste flaky: o que é? Como acontece? Como evitar? Como lidar com ele? Para saber o que fazer quando se deparar com esses testes, preparamos um conteúdo completo sobre o tema.
Mas o que é um teste flaky?
Diz-se que um teste é flaky quando passa ou falha de maneira não deterministicamente (quer dizer, aleatória), na mesma configuração e mesmo ambiente de execução, como código, sistema operacional, etc.
Por exemplo, você roda um teste uma, duas, três, dez vezes e ele passa, mas na décima primeira, ele falha, sem que qualquer outra modificação no teste ou no ambiente tenha sido feita, gerando um comportamento não determinístico.
Um teste pode falhar de forma não determinística, porque tenta acessar um servidor local antes que o servidor esteja pronto para aceitar solicitações.
Testes flakies podem afetar negativamente o processo de desenvolvimento de software em, pelo menos, duas formas importantes:
- Aumento do custo: na presença de testes flakies, pessoas desenvolvedoras não conseguem decidir se uma falha é devido a uma indicação de um problema real ou se é um falso alarme. Até mesmo testes que passam podem esconder falhas reais. Devs têm que depurar o problema, o que consome muito tempo.
- Desconfiança: testes imprecisos podem afetar negativamente a confiança das equipes no processo de testes de software. Devs podem começar a ignorar os resultados dos testes, enfraquecendo essa cultura.
Na Microsoft, a presença de testes em falhas impõe um ônus importante para pessoas desenvolvedoras. Por exemplo, equipes de pesquisa da empresa relataram que 58 devs da Microsoft consideraram os testes flakies como a segunda razão mais importante, entre 10 razões, para atrasar a implantação de software.
No GitHub, foi observado que “1 em 11 commits teve pelo menos um build quebrado causada por um teste flaky“. No Google, diversas falhas de testes são devidos ao seu comportamento flaky. Outras organizações compartilham problemas semelhantes.
Por que um teste flaky ocorre?
Em um estudo feito em 2014, Qingzhou Luo, engenheiro de software do Google, e colegas propuseram uma taxonomia para as causas (e eventuais resoluções) de testes flakies em projetos Java.
De acordo com o trabalho, as cinco causas comuns que levam a testes flakies são:
- Uso de ‘Async Wait’: ocorre quando a execução do teste faz uma chamada assíncrona e não espera adequadamente pelo resultado da chamada antes de utilizá-la.
- Uso de concorrência: quando o não determinismo observado na saída do teste é devido a diferentes threads interagindo de forma sub-ótima; por exemplo, devido a condições de corrida, violações de atomicidade ou bloqueios de deadlock.
- Dependência da ordem dos testes: quando o resultado de um teste depende da ordem no qual os testes são executados. Por exemplo: um teste x depende de um teste y, se x ler de uma variável global modificada por y. O teste y passa (ou falha) dependendo se o teste x for executado antes de y.
- Vazamento de recursos: quando o aplicativo não gerencia adequadamente (adquire ou libera) um ou mais de seus recursos, por exemplo, a conexões de banco de dados, podendo levar a testes intermitentes.
- Uso da Rede: quando um teste depende do uso de recursos de rede, nem sempre é possível garanti-los, causando testes flakies.
Como mitigar os testes flakies?
Existem três principais estratégias para lidar com testes flakies:
- prevenção
- detecção
- reexecução (após falha)
Agora vamos ver em detalhes cada uma dessas estratégias:
1. Prevenção
A prevenção consiste em regular o desenvolvimento de software de forma que evite testes flakies por design. Por exemplo, no Google, pessoas desenvolvedoras são encorajadas a escrever testes single-threaded para evitar testes flakies.
A prevenção é uma atividade desafiadora, em particular, porque devs precisam se policiar para escrever testes além do teste de unidade.
2. Detecção
A detecção consiste em analisar a suíte de testes antes que esta seja executada durante o processo de teste de regressão. Essa estratégia tem sido pesquisada intensivamente nos últimos anos.
No entanto, as abordagens de detecção ainda são bem limitadas. Por exemplo, detectores de testes flakies que funcionam de maneira estática ou dinâmica estão limitados em escopo.
3. Reexecução
A reexecução consiste em executar novamente a suíte de testes múltiplas vezes, a fim de identificar comportamentos divergentes entre as execuções.
Embora a reexecução seja uma estratégia popular na indústria de software, essa abordagem é cara e contraprodutiva. Reexecutar os testes consomem não somente recursos computacionais, mas também o tempo das pessoas desenvolvedoras.
No Google, é estimado que atividades de reexecução para fins de detecção de testes flakies consumam cerca de 2 a 16% do orçamento dedicado para atividades de teste.
Como lidar com testes flakies?
Sabendo que testes flakies são um problema recorrente na indústria de software e que as abordagens existentes para detecção e remoção destes testes ainda são limitadas, pessoas desenvolvedoras precisam implementar estratégias para que a confiança e a cultura de testes não sejam impactadas pela dificuldade em lidar com esses testes.
A seguir, apresentamos algumas estratégias utilizadas para aumentar a conscientização da existência de testes flakies.
Odeneye
Odeneye é um produto criado internamente pelo Spotify, que tem como objetivo visualizar a evolução das execuções das suítes de testes, de forma a apontar eventuais falhas por testes flakies. O Odeneye fornece a seguinte visualização:
Na figura, cada quadrado verde representa um teste executado com sucesso, enquanto que uma bola laranja pode indicar a existência de um teste flaky. Uma sequência de bolas laranjas fortalece a existência de testes flakies.
Flakybot
O Flakybot é outro produto criado internamente pelo Spotify. Este bot ajuda pessoas desenvolvedoras a garantir que um teste flaky não será incorporado na base de código durante o processo de revisão.
Para isso, devs podem chamar o bot e passar parâmetros para execução dos testes. Após essa ação, o bot retorna a saída do teste, o que ajuda a pessoa revisora do código a decidir se o teste deve (ou não) ser incorporado na base.
Assuma propriedade
No GitHub, a saída encontrada foi atribuir a propriedade de resolver o teste flaky para a pessoa que o introduziu. Nesse caso, minera-se os logs do git até encontrar o primeiro commit introduzindo o teste flaky e adiciona-se um ticket para a pessoa que foi responsável por aquele teste, para que corrija o comportamento.
Conclusão
O teste flaky é um teste que apresenta comportamentos não determinísticos. Embora algumas causas de sua manifestação já tenham sido catalogadas, na prática, ainda é difícil detectar a presença desse problema em uma suíte de testes.
Neste artigo, apresentamos algumas formas de evitar e lidar com os testes flakies, de forma que otimize recursos e o tempo de trabalho de pessoas desenvolvedoras.
Caso você já tenha observado esse comportamento na sua empresa ou projeto, comente abaixo: como você lidou com ele? ?
