Introdução

Espero que você tenha se alimentado dos outros tópicos antes de chegar aqui, porque essa discussão divide nações na área de TI há tempos.

Uns alegam que escrever testes é besteira e onera muito o tempo de desenvolvimento, e outros dizem que não, que se ganha tempo. Uns dizem que uma task de 4h se torna uma task de 8h ou mais escrevendo testes, outros dizem que com 4h a 6h se escreve a mesma task com garantia de qualidade e sem que ela precise voltar a desenvolvimento devido a bugs.

Depois de alguns anos trabalhando com desenvolvimento e tendo praticado testes nos últimos anos, eu tenho algumas percepções para compartilhar, então tenha em vista que é uma opinião, e você tem direito de concordar ou discordar.

Breve diálogo

Então vamos lá. Uma conversa para entender alguns pontos sobre a discussão:

Pergunta: Escrever testes aumenta o tempo da tarefa?

Resposta: Depende, e sim, de muita coisa. A pessoa sabe testar? Tem experiencia com o projeto e com as ferramentas? O ambiente de testes está bem configurado? O projeto já tinha testes ou vai começar a ter agora?, etc. São muitas variáveis, mas vamos considerar o caminho feliz, o projeto teve o ambiente de testes configurado corretamente assim que foi iniciado, e logo já começaram a testar. Então tem vários exemplos, toda a cama de testes está rodando lisa, sem erros e sem necessidades, e a pessoa sabe testar, tem experiencia previa. Nesse caso não deveria demorar, mas o ideal seria contabilizar algum esforço a mais em pontos ou horas na tarefa. E isso o Engenheiro que vai definir, se precisa de 1h para escrever os testes, ou se não precisa. Em um caminho infeliz, onde não tem ambiente configurado, não tem testes de exemplo, a pessoa não tem tanta experiencia. Pode ser que seja demorado, que vaze o tempo da tarefa, e isso o gestor tem que ter em mente e aceitar para prosseguir, e capacitar o engenheiro para que ele possa executar a tarefa com experiência.

Como podemos ver na resposta acima, tem muita coisa que impacta na entrega quando você adiciona testes.

Mas acredito que os ganhos no futuro compensem as perdas do presente.

Tarefas testadas tendem a ter menos bugs, e a serem mais fáceis de se retrabalhar caso necessário. Além de que traz mais garantias de qualidade para o produto.

Testes podem ser requisitos de esteira de entrega continua, ou requisitos de pull request. Os mesmos servem como documentação de funcionalidades (auxiliando novos desenvolvedores que vão mexer em coisas prontas). Em alguns casos servem até mesmo como ferramentas de produtividade, por mais contraditório que pareça (na visão de quem não conhece ou não gosta de testes) se comparado com o título do artigo (vou abordar sobre isso quando for falar de TDD).

Pergunta: Por que eu deveria escrever testes se posso entregar a tarefa bem feita sem eles?

Resposta: Um engenheiro com anos de experiência que não prática testes, não é necessariamente um péssimo engenheiro, na verdade, ele pode entregar coisas complexas ou não, com muita qualidade. Mas a questão é quando você tira um pouco do zoom de cima da tarefa, e olha para as conexões que aquilo tem com o produto, com o processo e com as pessoas que trabalham ali. Escrever testes é mais que simplesmente ter arquivos .spec/test no projeto e mostrar números de Cobertura ou Quality Gate. É criar um ecossistema saudável sobre a vida do produto e fazer com que todo o ambiente seja mais simples de lidar em meio ao caos. Quando nós garantimos que uma tela se integra com outra e não precisa de uma verificação visual para saber que está funcionando, ou que uma funcionalidade nova está trabalhando como devido, nós aumentamos a escalabilidade, e sustentabilidade, do produto. Nós facilitamos o trabalho do próximo, além de ajudar a nós mesmos caso precisemos voltar naquele local para fazer algum trabalho.

Duras verdades

Escrevendo a resposta acima, me lembrei de uma frase de um livro de um escritor e engenheiro famoso (na qual não lembro nome, talvez o Eric Evans, ou o Uncle Bob?) que diz: "Um programador que não escreve testes, não é um bom programador!".

Essa afirmação pode ser dura e pode ferir o ego de algumas pessoas, confesso que feriu o meu no início.

Mas ele não tem a intenção de diminuir/ofender ninguém, mas sim, de abrir a nossa mente, nós como Engenheiros, temos que usar todas as ferramentas que simplifiquem nosso trabalho, devemos trabalhar de maneira inteligente.

É igual quando você fica escrevendo o mesmo trecho de código em todo lugar e não separa aquilo em uma biblioteca, não está errado, mas não é a maneira mais inteligente, não precisamos implementar coisas complexas para parecermos inteligentes, mas precisamos implementar o necessário da melhor maneira possível, isso é ser inteligente. Evitar retrabalho, desperdícios, e redundância em cima da mesma coisa.

Outro bom motivo para implementar testes em projetos, é que ótimos profissionais usam isso como filtro e como requisito para trabalhar em uma empresa. Já perdi a conta de quantas vezes ouvi de amigos, ou de pessoas que são referencias, ou li em artigos, textos, que a pessoa recusou uma proposta porque a cultura de desenvolvimento da empresa não era boa, que não tinham testes, ou esteiras, ou outros recursos de qualidade.

E por quê? Só porque não tem alguns describe() ou test() no projeto?

Não, na verdade, essas pessoas querem ambientes sólidos e escaláveis para se trabalhar, e querem evitar o caos descontrolado. Querem implementar as melhoras soluções em cima de um ambiente estável, se preocupar em fazer direito e não em refazer algo mal feito ou que quebrou.

A seguir vamos entender como testar as coisas no frontend, e você verá que não é um bicho de sete cabeças.