Como começar a automatizar testes?

Uma das maiores dúvidas que sempre escuto é: “Quero fazer testes automatizados, mas não sei por onde começar…”. Se você chegou até aqui, pode nem sofrer dessa dor, mas provavelmente já deve ter se deparado com aquele projeto legado (que pode crítico pro seu negócio) sem nenhum teste automatizado e se perguntou como seria adicionar esses testes. Bom, como sempre, não existe receita de bolo, ou bala de prata, para resolver esse problema, mas existem estratégias que podem ser consideradas para cada situação.

Quando falamos de estrutura de testes automatizados, a primeira coisa que vem à mente é a pirâmide de testes. Existe um motivo para ela, um deles é otimizar o uso dos testes automatizados e minimizar os possíveis impactos negativos que existem neles (sim, testes automatizados não vão resolver todos os problemas de teste e qualidade que possam existir no seu projeto). De forma resumida, vamos entender cada andar, da base ao topo:

• Testes unitários (unit tests): Testam a lógica do seu código a nível de unidade, por exemplo, um método pode ser considerado uma unidade. Por serem mais baratos de desenvolver, manter, terem pouco custo de manutenção e rodarem muito rápido, formam a base da pirâmide e devem ser em maior quantidade, isso porque o feedback é muito mais rápido e você quer achar possíveis problemas no seu código o quanto antes no seu processo de desenvolvimento;
• Testes de integração (integration tests): Testam a integração do seu código (aqui, é possível incluir também integração com serviços externos, os testes de API, que podem também ser outro andar, mas não vamos entrar nessa questão agora). Em menor quantidade que os unitários, já que custam um pouco mais e dão um pouco mais de trabalho de manutenção, consequentemente o feedback também é mais lento;
• Testes End-to-End (E2E) ou UI Testing: Simulam ações do usuário diretamente na sua interface. São os mais caros de desenvolver, manter e levam muito tempo para rodar, além de um custo computacional alto, logo, o feedback é muito mais lento e por isso se encontram no topo da pirâmide, em menor quantidade;
• Testes manuais: Em alguns modelos, adicionamos os testes manuais acima da pirâmide, na “nuvem”, que pode ser desde uma última validação de valor de negócio, teste exploratório ou visual, que ocorrem de acordo com a necessidade e portanto, não tem uma estrutura definida na pirâmide.

Mas então, precisamos começar a construir a pirâmide de testes por onde? Se eu já tenho muitos testes End-to-end, como faço parar chegar na pirâmide completa? São dúvidas importantes e que depende de alguns fatores:

Valor dos testes

Tenha em mente que testes são uma ferramenta, assim como qualquer outra que você usa no seu projeto, deve entregar valor de alguma forma. Muitas das equipes que não fazem testes automatizados tendem a não ver valor ou até achar que essa ferramenta trará mais problemas do que soluções, por isso é importante trazer esse valor para o time e nada melhor do que fazer isso na prática:

1. Priorização dos testes: Em um cenário de um time ou projeto já em andamento, começar a estrutura de testes pela base da pirâmide pode não trazer o valor que você precisa para convencer o time, portanto priorize quais testes fazer primeiro. Pode ser uma feature que causa muitos bugs em produção e que ao se adicionar alguns testes de integração, fez diminuir a incidência dos mesmos ou mesmo automatizar os testes regressivos com end-to-end, livrando o time de mais trabalho manual. Essa priorização ajuda tanto no retorno rápido de valor quanto na percepção de que testes automatizados podem ajudar seu time;
2. Adicione o desenvolvimento dos testes na sua estimativa: Uma vez que o time está enxergando valor nos testes automatizados, é hora de olhar para seu processo de desenvolvimento e adicionar os testes no mesmo. Evite ter sprints ou épicos apenas para desenvolver testes, isso pode levar a percepção de que testes demoram muito tempo para serem desenvolvidos, prefira adicionar um esforço menor por tarefa, mas garantir que todas essas tarefas sejam entregues com testes. Na prática funciona assim: podemos dizer que toda tarefa é uma alteração em um ou mais trechos de código, se garantirmos que esses códigos ganhem testes caso não tenham ou ganhem novos casos que contemplem essa alteração, estamos adicionando o esforço de testes no escopo da tarefa. Assim, além de aumentar a segurança do time nas novas tarefas entregues, seu sistema irá constantemente ganhar novos testes, aumentando a cobertura sem deixar que novas entregas aconteçam. Ah, aqui vale um adendo: não tem problema ter uma task para configurar ferramentas de teste automatizado no projeto, já que elas tendem a demandar um tempo para isso, principalmente as de end-to-end, mas apenas se for o caso de ninguém no time ter experiência com essas ferramentas;
3. Metrifique e acompanhe seus testes: Existem muitas ferramentas que medem a cobertura de testes ou que apontam a saúde deles e é comum alguns times ou empresas usarem esses valores como metas ou pré-requisitos para as entregas. Isso não é recomendável pois torna a cobertura dos testes uma obrigação e não uma vantagem. Os testes devem trabalhar para você e não o contrário. Use ferramentas de cobertura de testes para acompanhar a saúde dos testes e também da sua aplicação. Você provavelmente altera alguns trechos mais que outros, portanto, esses serão os que vão ganhar testes primeiro e também os que mais sofrerão alteração de testes. Por outro lado, trechos em que ocorrem pouca ou nenhuma alteração nos testes podem apontar código inútil e que pode ser excluído ou movido para outro lugar na sua aplicação. Use isso para aumentar a qualidade do seu projeto, indicativos de onde alteramos mais pode significar algum nível alto de acoplamento ou até um problema maior na arquitetura do seu projeto. Mas atenção, só grandes alterações por conta disso quando alcançar uma cobertura de testes que considere saudável (eu sei, eu sei, eu também adoro apagar código inútil).
4. Já tenho alguns testes, o que fazer?: Caso você já tenha algum teste, de algum andar superior da pirâmide, faça uma análise profunda deles levando em conta manutenibilidade, confiança (com que frequência os resultados são inconsistentes, o famoso flaky test) e se a velocidade de feedback é satisfatória. Se seus testes vão mal na maioria desses requisitos, não tenha medo de jogar esses testes fora! Se você considera que os testes existentes já entregam valor, trabalhe para construir os outros andares da pirâmide! Em ambos os casos, priorizar e entregar valor mais rápido é a chave para alcançar a construção da pirâmide!
5. Próximos passos: Hora de se reunir com o time e decidir como os testes vão servir. Colocar na sua pipeline automatizada de releases é a pratica mais comum. Alguns times gostam de rodar baterias de E2E completas em datas e horários específicos, outros só gostam de rodar conforme a necessidade! Algumas ferramentas de controle de versão permitem disparar os testes unitários no momento em que é feito um commit ou quando um pull request é aberto. Novamente, entenda o que pode funcionar melhor para o seu caso e teste a estratégia que considera a melhor (quem disse que não se testa o teste)!

Conclusão

Mais importante do que qual estratégia utilizar, como implementar e tudo mais, é saber qual problema você quer resolver com testes. Pode ser só aumentar a qualidade das suas entregas, a velocidade ou diminuir a dor dos testes manuais. Uma vez que você sabe qual o problema, não tenha medo de jogar testes velhos fora, inverter o cone pra que ele vire uma pirâmide, construir novos andares da sua pirâmide de testes ou até remover os que não fazem sentido! No final do dia, o importante é que os testes automatizados trabalhem para você e resolvam o problema que você quer resolver!