Este conteúdo foi inicialmente publicado na Newsletter da Talking About Testing.
Testes automatizados devem fornecer feedback confiável aos times de desenvolvimento de software. Portanto, seus resultados devem ser determinísticos.
Testes determinísticos são àqueles que sempre que executados com as mesmas entradas, retornam as mesmas saídas (ou seja, os mesmos resultados esperados).
Porém, às vezes introduzimos testes não-determinísticos às suítes de testes (os famosos flaky tests) e nem percebemos.
Depois de algum tempo, tais resultados não-determinísticos (e portanto não-confiáveis) começam a aparecer.
Em tais ocasiões, os times perdem tempo investigando os motivos das falhas, até perceberem que o problema eram os testes (não a aplicação sendo testada).
E quando tais testes pegam um problema real, o time já perdeu a confiança na suíte de testes, deixando bugs reais passarem.
Você deve estar se perguntando. “Como previnir tais situações?”
Uma forma de identificar testes não-determinísticos é ativar sua re-execução no pipeline de integração contínua (CI – continuous integration), onde caso o teste passe quando re-tentado, é marcado como flaky.
Porém, o que fazer quando o teste é flaky (mas não sabemos) e passa na primeira execução no CI?
Nestes casos, quando percebermos que o teste é flaky já é tarde demais.
Ou seja, o teste já faz parte da suíte de testes que deveria fornecer confiança aos times.
Para evitar tal problema, minha sugestão é “queimar” novos testes (ou testes sendo modificados), para garantir que passam um determinado número de vezes antes de poderem fazer parte da suíte de testes principal.
Quando digo “queimar”, quero dizer executar o mesmo teste n vezes no CI, antes de permitir que tal teste seja considerado determinístico, e portanto, um teste no qual podemos confiar quando estiver falhando.
A dinâmica seria a seguinte.
Na criação de um novo teste, tal teste seria marcado (de alguma forma) com uma etiqueta, tal como @burn (queirmar em inglês), por exemplo.
No CI, testes com tal etiqueta seríam executados 10 vezes, por exemplo, e só quando passarem 10 vezes consecutivas, seria permitido que viessem a fazer parte da suíte de testes principal.
O mesmo vale para testes sendo modificados, visto que modificações em testes poderiam torná-los não-determinísticos também.
Dessa forma, podemos diminunir o número de testes não-determinísticos, aumentando a confiança dos times, e ajudando-os a encontrar falhas reais antes de tais problemas chegarem aos usuários finais.
E você, quais táticas tem usado para previnir testes não-determinísticos?
Estou curioso para saber.
E se você ainda não havia pensado nisso, espero que este conteúdo te ajude a começar a pensar, ou melhor ainda, a colocar tal técnica em prática.
Por fim, se você está usando Cypress para seus testes automatizados, recomendo dar uma olhada na biblioteca cypress-grep, mantida pelo time do Cypress. Recomendo olhar especificamente para a funcionalidade burn.
Além disso, recomendo dar uma olhada na funcionalidade de Test Retries, disponível no Cypress Cloud.
Até a próxima.
Ficou curioso(a) e quer aprender mais sobre automação de testes web? Conheça meus cursos no Udemy.
- Cypress básico
- Cypress intermediário
- Cypress avançado
- Boas práticas em automação de testes com Cypress
- Testes end-to-end com Cypress
- Testes de regressão visual com Cypress e Percy (básico)
👋 Até a próxima e bons testes!
TALKING ABOUT TESTING 