O Guia Inicial de Testes de Software

Qualquer aplicação que existe precisa ser testada antes de ir para produção, isso é bem melhor que apertar o botão do deploy e o WhatsApp começar a cantar a quinta sinfonia do caos em instantes. Cliente x não consegue terminar tarefa y, ferramenta z saiu do ar... Claro, não dá para adivinhar o futuro, mas dá pra fazer algo muito perto disso.

Fazer testes é uma tarefa chata, monótona, mas absurdamente necessária e importante. Aquele joguinho que simula a copa para tirar onda com os amigos não vai precisar de teste nenhum, mas se tem um cliente pagante no fim da equação, tem que ter teste: é o certificado digital de segurança e qualidade do seu projeto.

Conheça um pouco da história dos testes logo abaixo, ou pule direto para o que serve cada um. Este é um texto introdutório para o conhecimento dos testes, em um post futuro, posso falar sobre testes de performance, carga, segurança, usabilidade, regressão, aceitação, CI/CD, cobertura e outras coisas!

Quem São, Onde Vivem, O Que Comem?

Não vamos falar dos anos 50-70, nessa época o projeto era praticamente feito no hardware, e testes era algo impensável. Mas pelos anos 90, Kent Beck criou o SUnit (que virou os testes unit que conhecemos hoje). Pela primeira vez na história os desenvolvedores puderam ter um padrão para escrever código que servia para testar outro código. Isso criou o termo TDD (Test-Driven Development), que trazia a ideia de que o teste não é o fim, mas parte do processo, fazendo parte da arquitetura.

Depois dos anos 2000, conforme o hardware e capacidade de software foram avançando e escalando, rodar testes manuais para grandes projetos começou a ficar insustentável, e daí veio o termo Pirâmide de Testes, com a ordem e necessidade de cada um.

Hoje, o que temos é chamado de Shift-left: uma esteira de testes, um após o outro, com análise estática, compilador, etc.

Todos os Tipos de Testes

Análise Estática

Essa é a primeira camada, antes de rodar qualquer teste antes desse, a análise estática faz uma inspeção completa no seu código buscando falhas lógicas e quebras de contrato. JavaScript tem ESLint, TypeScript tem o compilador do TS, PHP tem o PHPStan, Go tem o go vet e staticcheck, Rust tem seu próprio compilador com Borrow Checker.

Testes Unitários

Os mais usados, disparado. Com os testes unitários você vai testar a menor unidade lógica de forma isolada, ela pode ser - por exemplo - uma função ou classe. Não tem contato com API externa nem nada de produção, o que é usado são mock-datas, informações falsas que vão validar regras de negócio.

Cálculos de frete, regras de desconto, manejo de serviços, são validações extremamente rápidas que usam testes unitários.

Curiosidade: PHP tem PHPUnit ou Pest, JS/TS tem Vitest ou Jest. Já Go e Rust lidam com testes como cidadãos de primeira classe, não precisa de nenhum framework externo, ambos possuem nativamente uma estrutura completa de testes.

Testes de Integração

Diferente dos testes unitários, os testes de integração vão se comunicar com bancos de dados reais, filas, cache ou sistemas de arquivos. Aqui o objetivo é garantir - por exemplo - se o repo salva corretamente no PostgreSQL, ou que a mensagem chega no RabbitMQ.

Ah! mas então vão testar direto no meu projeto em produção?? Calma! Não. O mais comum é testar em um container Docker descartável e isolado (conhecido como TestContainer), em que seeds são geradas, ou em um ambiente exclusivo para testes.

Testes e2e (End to End)

Nessa camada, o objetivo é simular o usuário real. Testes e2e aplicam 30, 40, 50 ou mais operações diferentes e validam o fluxo crítico. Dá para fazer, por exemplo, diversas situações em que o cliente acessa o site, e faz várias operações, incluindo se ele consegue fazer login, adicionar produto no carrinho de compras, passar o cartão de crédito, calcular frete, e etc.

Lembre-se de que usei calcular frete como teste unitário, mas aqui é diferente, o teste e2e vai simular o usuário acessando a página, e calculando o frete diretamente de lá. Estes testes são os meus preferidos, e agradeço muito a era da IA, pois preciso apenas verificar se eles foram escritos corretamente e estão funcionando 🙏.

Smoke Tests

Depois do deploy é verificado se tudo está nos conformes. Então um script simples pode fazer ping em algumas rotas e verificar se retorna 200. Caso retorne 500, um rollback automático acontece e o time de desenvolvimento corre para entender o que aconteceu.

Curiosidade: smoke testes vem de uma brincadeira famosa da engenharia de hardware, que é mais ou menos assim, em português: "ligou na tomada, saiu fumaça?"

Estes testes foram feitos para serem simples e rápidos. Apesar de não parecer, são uma verificação extra importante pois vai verificar como o projeto está no hardware real, em produção.

Mutation Tests

Ok, esse pouca gente usa. Eu mesmo nunca usei! Mas conhecer não faz mal pra ninguém. Mutation test é a corregedoria, quando está escrito na parede "Who tests the tests??", ele aparece e diz em voz alta: "EU!"

Para saber se os testes realmente funcionam e a cobertura não é falsa, os testes de mutação inserem bugs propositais no projeto, como trocar um simples + por um - ou inverter um boolean. Depois de fazer a maldade, ele roda os testes e espera que eles errem, se passar, o alerta vermelho extremo liga: os testes estão cegos, e precisam ser urgentemente revistos.

Vai de Cada Caso

Escrever testes é sim aumentar o tempo de desenvolvimento, mas reduz muito a dor de cabeça depois (acredite, pular os testes é pedir por isso). Quer evitar hotfixes, retrabalho e problemas em produção com pessoas reais? Só os testes podem minimizar isso.

Sim, são chatos, mas são cruciais.