Por que o time de engenharia deve confiar no resultado dos testes
No appear.in temos a mentalidade de que para criar uma aplicação que os nosso usuários amem, e que possa ser mantida a longo prazo, precisamos criar testes automatizados (na maior quantidade de camadas da aplicação possível)
Para cada funcionalidade nova na aplicação , para cada refatoração feita para melhorar o código e para cada bug encontrado, testes são criados para prevenir a quebra da aplicação no futuro.
Existem diferentes tipos de testes automatizados. Alguns são muito confiáveis e rápidos para rodar, como os testes de unidade. Outros não são tão rápidos quanto os testes de unidade, mas ainda são mais confiáveis que outros, como os testes de integração. Mas ainda tem os testes de UI, que por natureza são as vezes flaky.
Testes automatizados existem no processo de desenvolvimento de software para fornecer feedback rápido ao time enquanto a aplicação evolui. Devido a isso o resultado dos testes precisa ser confiável, pois se você não pode confiar no resultado dos teste, porque perder tempo criando eles.
Como mencionado antes, algumas vezes testes de UI são flaky, e isso basicamente acontece porque sua intenção é testar a aplicação de ponta a ponta, interagindo com o sistema como os usuários fariam, e algumas vezes, problemas de rede, lentidão no servidor, e muitos outros aspectos podem afetar o resultados dos testes, causando falsos negativos.
Se os testes falham com resultados falsos negativos o tempo todo, o time de engenharia perde a confiança neste conjunto de testes, e quando um bug verdadeiro é encontrado por estes testes, eles vão pensar que o bug não existe, porque eles já estão acostumados a ver os testes falharem, mesmo quando não há problemas com a aplicação no geral.
Até mesmo o Google sofre com testes flaky, como você pode ver neste post, e uma das técnicas que eles mencionam para evitar isso, e que nós no appear.in decidimos usar também, é a técnica de retestar apenas os testes que falharam, para evitar resultados falsos negativos. Com certeza esta não é a melhor opção, mas ao menos ajuda.
Os nossos testes são construídos usando o Protractor, o framework oficial de testes e2e para aplicações AngularJS, e alguns deles algumas vezes falham por serem flaky. Mas, graças ao Philipp Hanck, nosso especialista em WebRTC, agora nós integramos os nossos testes com um módulo node chamado Protractor-Flake (o Philipp foi quem achou, eu implementei, e ele revisou e aprovou meu pull request). Esta biblioteca basicamente nos habilita a re-executar apenas testes que falharam, e definir quantas vezes queremos repetir tais testes.
Outra coisa mencionada no mesmo post, que nós já fazemos também, é colocar testes flaky em quarentena, para que possamos investir tempo em identificar porque eles não são confiáveis, e tentar torná-los mais robustos e confiáveis no futuro. E se isso não for possível, simplesmente removemos do conjunto de testes, pois é melhor não tê-los, do que tê-los falhando quando não deveriam.
Além disso, sempre que possível estamos buscando formas de tornar os testes de UI mais confiáveis, através de refatoração, consultas a profissionais do próprio time do Protractor e outras abordagens. O importante e buscar a melhoria sempre!
E você, sofre com testes flaky também? Compartilhe seus pensamentos e vamos criar softwares melhores, que não só nossos usuários amam usar, mas que também possam ser mantidos a longo prazo pela equipe de desenvolvimento.
Gostou deste artigo? Legal! Curta e compartilhe-o com seus amigos nas redes sociais.
E bons testes! =)
Um obrigada especial ao Philipp Hancke e ao appear.in.
Esse post foi publicado originalmente no Medium em Inglês.
TALKING ABOUT TESTING 