#TesteSemNeura - Testes unitários, como comecei e como posso te ajudar.

Eai pessoal, tudo certo? Hoje vou falar para vocês sobre um assunto que foi um divisor de águas na minha carreira e que pode ser na sua também, inclusive nas minhas entrevistas eu sempre pergunto o grau de familiaridade que o candidato tem com as ferramentas de teste.

Meu objetivo nesse post é fazer com que você saia daqui pelo mais 10% apaixonado(a) sobre testes ou caso você é aquela pessoa que diz "codar um teste é perca de tempo" ou "exige tempo para fazer bem feito com teste" eu quero que você saia daqui desmistificando isso de uma vez por all, ok? Falo isso porque eu pensava da mesma maneira "não tenho tempo para fazer teste", "é complexo e eu não consigo", "o time não dá abertura para fazer isso" e inúmeras outras coisas que eu pensava para justificar a minha negligência.

Mas vamos lá, esse é um dos primeiros posts que eu vou falar sobre testes então esse artigo tende a ser mais teórico e motivador (tipo auto ajuda mesmo kkk), para exemplificar bem vou compartilhar algumas experiências que já tive como dev e como lead.

Testes unitários

Já ouviu falar? Vou ser o mais breve possível, esse teste tem a intenção de testar pequenas unidades do seu sistema, exemplo no frontend: Um botão, exemplo no backend: Um função que separa livros por gênero.

Memorize esses exemplos porque nós vamos trabalhar neles daqui pra frente!

Por que testar?

Vou responder essa pergunta com duas situações e é provável que você vai pensar "mermão eu passei/passo por isso".

Situação 1: Você precisa alterar uma função que está em produção que é chamada em vários locais do código. Você não fica com medo de alterar algo nesse código?, até a equipe de QA sente um calafrio na espinha quando vê uma task dessa.

Situação 2: Criar uma função de um comportamento cheio de casos específicos. Essa daqui é a coisa mais chata que existe, você implementa, salva, testa manual e verifica se funcionou, agora que funcionou implementa um novo caso e quebrou o caso que já tinha testado, quem nunca né?

Essas situações são bastante corriqueiras! Quando você se deparar com situações do tipo, alguém com medo de subir uma nova build, ficar apreensivo em adicionar mais um if em uma função, desconfiar do seu próprio código pensando "nem eu sei como que isso ta funcionando mas funciona e é isso ai kkkk" você caiu na malha fina dos testes! Testes impactam o negócio diretamente nos prazos, decisões e bem estar da equipe, nesse meu tempo de indústria vital eu já vi algumas features serem cancelados ou terem seu prazo "esticado" porque o time não conhece o código atual e não sabe o que vai acontecer se for alterado, então tem que estudar o código atual para saber até onde vai quebrar caso sofra alguma alteração. Já pensou se tivesse um teste? Provavelmente não teríamos esse problema. Isso é um exemplo claro da situação 1 e 2 juntas, alterar um comportamento ou regra do software é algo comum em muitos projetos.

Como foi para mim

No começo foi complicado colocar na minha cabeça o porque de testar coisas óbvias, era tipo "isso é tão claro, porque eu preciso testar isso?". Lembra do exemplo do botão? Vamos exemplificar alguns casos de teste para ele.

Button

✓ Deve renderizar a label do botão

✓ Deve ser clicável

Óbvio não? Claro! Agora imagine duas novas tasks: "Adicionar um botão com label e ícone" e "Adicionar um botão somente com ícone". Você vai ter que alterar o comportamento desse botão adicionado alguns ifzinhos para exibir label, label e icone, e somente ícone. Te lembra a situação 2? Sempre que alterasse qualquer coisa nesses comportamentos teria que verificar manualmente se todos os outros casos estavam corretos, com os testes óbvios implementados você não precisaria retestar manualmente os casos antigos manualmente. A lição é por mais óbvio que o teste pareça sempre vai ter uma importância a médio prazo e até curto caso você tenha amigos de projeto que comentam algumas coisas no código e esquecem de descomentar e comitam. Eu já fui "salvo" diversas vezes por testes óbvios! porque eu era esse amigo 😅

Outra coisa que eu pensava erroneamente também era sobre os prazos, "não dá tempo fazer", eu não fazia teste porque não dava tempo mas estava levando o dobro de tempo ou mais para implementar algo novo porque eu precisava testar manualmente a cada iteração nova no componente e o pior.. Ficava com medo de ter deixado passar alguma coisa, então faça o seguinte questionamento para você e sua equipe, Você não tem tempo para testar mas tem tempo para corrigir bugs em produção e tempo para fazer revisões de códigos antigos para entender o comportamento das funcionalidades? Acredito que sua equipe também pode pensar assim porque de fato pensa na entrega e caso tenha bugs você vai ter tempo para corrigir esses bugs, mas isso é certo para você?

Depois que eu comecei a implementar eu comecei a me questionar muito sobre "isso é realmente necessário?". Meu conselho é que você continue implementando os testes, eu garanto não que eu seja alguém hahaha que irão aparecer os casos "nossa ia quebrar se eu não tivesse o teste", "ainda bem que tem o teste para ficar verificando isso", "refatorei e estou de boa porque eu sei que o teste passou".

Tome uma decisão

Se você chegou até aqui e ainda pensa que teste é perca de tempo ou que não tem tempo para fazer eu sugiro que pare de ler e volte depois, pode ser que para você não faça sentido agora. Isso mesmo, volte quando você estiver vivenciado mais as situações acima, talvez você tenha passado pouco por elas ainda. Já vi pessoas do meu time saírem de "fazer isso é chato" ou "é perca de tempo" e alguns meses depois cair na real e ver que estavam errados. Então se você está disposto a continuar descobrindo mais sobre testes eu já fico muito feliz!

Próximos passos

Eu aprendi o porque testar, quero continuar aprendendo como testar e quero contribuir com as pessoas que passam por os desafios diariamente que citei acima, então resolvi fazer vários artigos para ajudar vocês a saírem da zona de conforto, ser um dev melhor e transformar o time que vocês trabalham, estou disposto a ajudar com os próximos tutoriais e conto com a ajuda de vocês para que a gente atinja mais pessoas e mais times por aí a entregar melhor e sem medo.