O mundo de automação evoluiu e hoje temos muitas opções de ferramentas e bibliotecas para automação de testes.
Neste artigo, vou compartilhar a minha heurística de como escolho as ferramentas ideias para a equipe de desenvolvimento, usando testes E2E como exemplo.
A heurística é a seguinte:
- 💻 Linguagem de programação predominante na equipe/empresa
- ⭐ Estrelas do GitHub
- 📚 Facilidade de compreender a ferramenta
- 🐛🔍 Facilidade de depurar o teste
- ✍️✨ Facilidade de escrever o teste
💻 Linguagem de programação predominante na equipe/empresa#
Esta é a primeira coisa que eu procuro em uma ferramenta.
Se encontro alguma ferramenta que a minha equipe ou empresa já conhece muito bem, só precisamos aprender como utilizar a ferramenta evitando o tempo de aprender como funciona uma linguagem nova.
Vamos supor que na minha equipe e empresa, Java e TypeScript são as linguagens mais utilizadas.
⭐ Estrelas do GitHub#
As estrelas no GitHub podem oferecer insights valiosos sobre quais ferramentas têm mais chances de receber suporte no futuro. Isso ocorre porque um maior número de estrelas pode indicar que mais pessoas estão utilizando e apreciando uma determinada ferramenta.
O site chamado GitHub Star History pode me ajudar com isso. Eu consigo colocar o repositório git das ferramentas e comparar a tendência das estrelas no github.
Por exemplo, fiz uma pesquisa e fiquei interessado em três ferramentas: Playwright, Cypress e Robot Framework. `
Vamos ver como fica a tendência das estrelas destas três ferramentas utilizando o GitHub Star History:
Então, a primeira ferramenta que vou testar seria o Playwright e depois Cypress.
O Robot Framework já descartei nesta fase.
📚 Facilidade de compreender a ferramenta#
Não confunda esta etapa com facilidade de escrever o teste!
Qualquer ferramenta de testes possui um conjunto de conceitos que você pode ou não estar familiarizado.
Não quero facilidade em escrever testes ainda, pois sei que a parte trabalhosa de um teste** é mantê-la!**
E para facilitar a manutenção destes testes, preciso compreender bem como a ferramenta funciona.
E quanto mais fácil de entender e compreender, melhor.
No meu caso, como eu tenho uma boa experiência com Selenium, o Playwright foi muito fácil de compreender. Parece uma versão muito melhorada do Selenium.
O Cypress já foi diferente. A maneira como ele executa os testes no browser não é bom.
Um exemplo disso é a dificuldade de ir em outra aba. É possível mas, na minha opinião, é gambiarra pura.
E um outro exemplo de um ponto negativo é como ele executa seu código de teste.
E assim por diante.
Pode ser fácil de escrever testes no cypress, mas o ponto negativo é muito maior que pontos positivos.
Descarto aqui o cypress.
🐛🔍 Facilidade de depurar o teste#
Agora só falta verificar se o Playwright fornece ferramentas para depurar o teste.
Esta parte é crítica. Quando o teste falhar, quero saber exatamente onde e por que falhou o teste.
E por enquanto o Playwright passou no teste também! Ele tem o trace viewer que facilita a depuração.
✍️✨ Facilidade de escrever o teste#
Finalmente a última coisa que vejo é a facilidade de escrever o teste.
Na verdade, nem vejo muito este ponto pois existem técnicas de programação que facilita a escrita dos testes independente da ferramenta e da linguagem.
Mas quanto menos nós escrevermos para facilitar, melhor.
E, no meu exemplo, Playwright funciona bem pois podemos escrever o código em Java ou Javascript. E a equipe já tinha experiência com Selenium que facilita a escrita dos testes também. (É praticamente igual a escrita).
Ou seja, escolhi o Playwright para escrever os testes E2E da equipe.
E se nenhuma ferramenta passar por estas heurísticas?#
Nesta situação, temos alguns caminhos. Por exemplo:
- Escrever sua própria solução de biblioteca de testes
- Ajudar a ferramenta open-source em questão com contribuições
- Usar a ferramenta sabendo que pode trazer dificuldades futura
Veja se vale a pena o investimento. Pois cada uma delas vai exigir tempo e dedicação da equipe e da empresa.
Conclusão#
Muitas equipes e empresas escolhem a ferramenta de testes que facilitem a escrita dos testes.
Esta decisão está baseada na seguinte mentalidade:
“Se o teste for fácil de escrever, os times vão adotar com maior probabilidade. E também ocupamos menos tempo dos times escrevendo testes”.
Esse é o pior jeito de tomar decisão da escolha da ferramenta, pois a maior dificuldade de um teste automatizado é a manutenção e não a escrita!
Desenvolvedores não gostam de escrever testes pois já viram muitos testes sendo abandonados ou ignorados a médio e longo prazo.
Ninguém quer escrever código inútil.
Não tomem decisões com esta mentalidade!
E sempre lembrando que quem deve escrever os testes automatizados é a equipe!
Qualquer dúvida, correção, sugestão, podem comentar à vontade.
Até a próxima!