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!