Sem sombra de dúvida, frameworks sempre ajudam a acelerar o nosso trabalho. Eles implementam uma porção de funcionalidades que reduzem a quantidade de código que nós temos que escrever, o que nos traz produtividade.
Mas e quando o assunto são testes, será que esse ganho em produtividade compensa o risco?
Eu particularmente nunca utilizei um framework de testes em nenhum dos projetos GO que já desenvolvi. Parte disso pelo fato de eu ter começado a programar em Go em 2012, “quando isso aqui era tudo mato”.
A algum tempo atrás, fiquei curioso em estudar frameworks de teste e comecei a olhar dois, o Convey e o Testify.
Enquanto pesquisava e estudava os dois, me deparei com uma talk, se não me engano do Rob Pike onde ele falava sobre testes em Go.
Ao assistir, fiquei surpreso com uma de suas falas que dizia para não utilizar frameworks de teste para testar código Go.
O motivo? Muito simples!
O package padrão da linguagem oferece tudo o que é necessário para se testar uma aplicação Go. Além disso, os criadores e mantenedores da linguagem garantem que esse package NUNCA terá bugs ou estará “quebrado”. Essa garantia faz com que possamos ter tranquilidade sobre a assertividade dos testes executados com o package padrão da linguagem.
Por outro lado, frameworks que são criados e mantidos pela comunidade, normalmente não dão essas garantias, ou seja, pode haver um bug ou problema no framework de testes que acabe gerando falsos positivos ou falsos negativos ao testar seu código.
Sendo assim, o framework pode deixar passar algum bug para seu código de produção.
Depois dessa talk, acabei abandonando o estudo dos frameworks de teste e continuei a aprender formas de otimizar a utilização do package padrão de testes da linguagem.
E você? Concorda com esse ponto de vista? Já teve algum problema com frameworks de testes?
Deixe ai nos comentários!
Obrigado por ter lido até aqui e até a próxima!
Neste caso eu sou a favor de usar uma lib externa. Venho usando o https://github.com/stretchr/testify fazem uns 4 anos e não tive problemas com ela. O meu argumento é que os testes só vão ser usados em ambiente de dev e CI/CD, então o foco maior deveria ser a developer experience. É diferente da escolha de um framework/lib que vai ser usado em produção, que pode afetar a performance ou algo assim. O Testify deixa o código dos testes muito mais legível e de fácil manutenção, o que ajuda bastante na qualidade de vida dos devs.