Nertec

Introdução

Tudo bem, é normal, mas saiba que a partir de agora sua vida vai mudar… rsrs.

Imagine que você possa testar de maneira autônoma todo o seu código/sistema, e se algo sair do normal, ou estiver com alguma falha, você será notificado, com o local e a anomalia encontrada.

Seria maravilhoso, não seria!? Bom, fique feliz, é isso que os testes fazem/oferecem.

E para que isso ocorra você precisa descrever o que eles devem fazer, depois executá-los, e eles farão o resto por você.

Em uma abordagem mais técnica, um teste é um código que executa outro código e verifica se o resultado esperado é verdadeiro, caso ocorra algum erro, ele irá retornar uma exceção informando os detalhes do ocorrido.

Nada mais é, que um ambiente de execução automatizado com uma série de ferramentas que irão garantir que as coisas estão funcionando como deveriam.

Muitas vezes no dia-a-dia, nós escrevemos algumas funções ou trechos de telas, e usamos console.log 's, ou inspecionamos os elementos, ou até mesmo fazemos depuração (o que é mais indicado) do código em execução.

Porém, algumas dessas técnicas não são as mais indicadas, nem garantem muita coisa, além de serem custosas e burocráticas.

Então se você as usa com o propósito de garantir o bom funcionamento, talvez não seja a melhor escolha, porque depois você precisa desfazer o que foi feito, e também, nada te garante que realmente está tudo em ordem. E no caso da depuração é um trabalho de diagnóstico, após ele acabar não tem como salvar e repetir tudo que foi feito, e normalmente só fazemos quando estamos tentando entender o código ou encontrar algum mau funcionamento.

O poder da automação

Quer garantir que o retorno da função está correto?

Que o formulário está validando os campos em todos os cenários de erros e notificando corretamente?

Que seu gerenciador de dados está fazendo todo o fluxo corretamente?

Então use testes! De unidade, ou de integração, ou algum outro que garanta isso de maneira assertiva, como os testes End-to-End (e2e).

Quando você usa testes para garantia de qualidade, além de tudo, você está mantendo uma documentação, um guia vivo de como as coisas devem ser executadas, ou quais comportamentos devem ocorrer, entre outras garantias.

Mas o melhor de tudo, você garante que as coisas sejam mais fáceis a partir daquele ponto.

Refatorações menos dolorosas

Por exemplo, se você precisa refazer uma funcionalidade já existente, sobre um código já escrito, os testes vão garantir a integridade e o acoplamento daquela funcionalidade com as demais.

Você fica mais tranquilo para mexer naquele código sem quebrar o que já existe e está funcionando corretamente. E caso você acidentalmente quebre alguma coisa, os testes vão te avisar, porque eles irão notar a anomalia, e indicar o cenário quebrado.

Se você ainda não acha que sua vida mudou, então continue 👇

Uma breve história:

Seu Tech Lead chega em você e te pede para corrigir um bug urgente. Em uma tela antiga do sistema, que você nunca mexeu (talvez nem estivesse na empresa/projeto na época), não sabe muito sobre a regra de negócio, e quando olha o código, é algo complexo, ou está mal escrito, com muitas funcionalidades avançadas que você nunca viu.

Você nem sabe por onde começar, não entende o que as classes ou funções fazem, não tem noção nenhuma de nada, e começa a ler, tenta depurar, para entender o que foi proposto ali.

Eis que você encontra junto do arquivo da classe/função, um arquivo de teste (se for JS com o prefixo .spec.js ou .test.js), e então você começa a ler os casos de teste, e percebe que alguém antes de você, passou por ali (seja na implementação da funcionalidade ou depois dela) e escreveu os cenários, os comportamentos, as regras de negócio. E então metade do seu trabalho está feito.

Você então executa aquele arquivo de testes, e um dos casos de teste quebram, bom, mais outra parte do trabalho está garantida, talvez você já tenha encontrado o problema, ou ao menos tem uma noção/guia de onde começar, ou o que fazer.

Você inspeciona no console - o caso com erro - e ele descreve o problema, um objeto está indefinido, ou era para receber uma string (texto) e está vindo um number (valor numérico).

Ouso dizer, que agora está mais simples de resolver o bug urgente.

Você implementa a solução, roda os testes daquele contexto novamente, e todos passam. Depois roda todos os testes juntos e todos passam.

Após uma rápida verificação manual (que talvez fosse sua única saída e você teria passado horas nela) e tudo está OK.

Correção enviada, PR feito e aprovado, problema resolvido.

Você para e pensa: "Caramba, resolvi em 40 minutos, mas achei que ficaria 1 ou 2 dias nesse bug, e era um problema muito bobo!"

Sentiu um alívio ao chegar no fim da história?

Bom, é isso que eu sinto quando vejo que escreveram testes para uma determinada funcionalidade que preciso mexer. Ou quando estou implementando alguma coisa e escrevo testes e eles vão passando (sem falsos positivos) e no final está tudo como deveria, e não perdi tempo com bugs inesperados (ou ao menos consegui corrigi-los rapidamente).

A vida é bela, mas nem sempre

Nem tudo são flores, às vezes os casos de testes não cobrem todos os cenários, algumas pessoas começam a testar e param na metade, outras pegam um projeto com testes e não dão continuidade.

Isso é bem comum, temos uma cultura de testes fraca no frontend, é bem difícil pegar projetos que foram testados desde o início.

Mas essa é uma oportunidade, você pode escrever o que estiver faltando, e contribuir para um dia de trabalho melhor para você e seus pares.

Acredito que a parte mais trabalhosa entre os cenários que eu citei, é quando não tem testes no projeto. Fazer a configuração do ambiente, em alguns casos, é algo bem trabalhoso, mas te garanto que vai valer a pena o tempo gasto, e o aprendizado.

Vantagens ocultas

Uma coisa que lembrei que os testes são ótimos: resolução de bugs.

Digamos que você está precisando resolver um bug chato em uma tela, e nada funciona. Como você poderia usar um teste para resolver esse bug mais rapidamente?

É simples, crie um caso de teste simulando o comportamento correto, onde o bug está ocorrendo e vá implementando a solução, até o teste passar, vai ser mais rápido e seu código estará mais limpo no final.

Quando usamos testes para implementar uma solução, seja praticando TDD (Test Driven Development) ou seja, para resolver um bug, você evita implementar coisas desnecessárias, pois o teste é como um gabarito, quando você o fizer passar, sua implementação estará correta, pois o teste reflete a funcionalidade em seu pleno funcionamento.

Por exemplo, temos um formulário controlado, e ao escrever no campo os dados não mudam o estado, e são apagados do campo logo em seguida.

Você pode escrever um caso, onde o cenário é o de erro, no teste iremos renderizar a tela, fazer a query para pegar o campo do formulário, simular uma digitação (entrada de dados) no campo, e em seguida clicar na ação do formulário (ou se o formulário tiver algum algoritmo reativo (como um debounce), esperar a reação), e então garantir que o campo foi preenchido.

Ao executar nosso teste, ele irá emitir alguns warnings e o caso de teste irá quebrar, então nós vamos ao código e começamos a implementar uma solução, seja escrevendo algo que falta, ou alterando/corrigindo algo existente.

Logo encontramos o erro, o valor inicial do campo estava undefined e formulários controlados, precisam ser instanciados com valores truthy, nós passamos um estado inicial verdadeiro (`string` vazia ou um valor de exemplo), e pronto, nosso teste começa a passar.

Conclusão

Essas são algumas percepções e algumas explicações sobre o que são testes.

Mas você deve estar com mais dúvidas agora, do que quando chegou neste artigo, então confira o próximo artigo para entender melhor sobre a literatura de testes, lá você irá entender um pouco mais sobre o que contempla esse tema.

Caso fique com dúvidas após ler os artigos seguintes, volte aqui e leia novamente.

---