O que realmente são testes unitários e por que a maioria dos devs erra na execução
Testes unitários são simplesmente verificações automatizadas de que cada função, método ou classe produz o resultado esperado quando isolada do resto do sistema. Isso parece óbvio até você tentar escrever um que passe em 80% dos casos e falhe no restante porque alguém injetou uma dependência de banco de dados no construtor. testes unitarios os unit tests sao uma pratica de desenvolvimento amplamente adotada, mas a implementação prática é onde o negócio fica interessante. Um teste unitário de verdade não acessa rede, não consulta disco, não chama APIs externas. Se o seu teste precisa de um container Docker rodando para funcionar, você escreveu um teste de integração, não um unit test. Confundir isso é o erro mais comum que eu vejo em code reviews.
Na prática, o fluxo funciona assim. Você identifica uma unidade de comportamento isolável dentro do seu código. Cria um fixture com dados controlados. Executa a função. Verifica o output contra o resultado esperado. Fecho o ciclo. Nada mais.
A regra dos três segundos que ninguém segue
Um teste unitário bem escrito leva no máximo três segundos para rodar. Três segundos. Se leva mais, tem algo errado. Eu vi times inteiros com suites de milhares de testes que levavam vinte minutos para executar. Vinte minutos. Ninguém rodava a suite antes de commitar. O teste virou decoração, não ferramenta de segurança. Aqui vai uma nuance que pouca gente conhece. O problema não é apenas o tempo de execução, mas o custo de manutenção. Testes que verificam detalhes implícitos da implementação — como se uma função específica foi chamada, em que ordem, com quantas iterações — se quebram sempre que a implementação muda, mesmo que o comportamento externo continue correto. Isso gera o que chamamos de teste frágil. E teste frágil é pior que não ter teste nenhum, porque dá uma falsa sensação de segurança e depois trava o time inteiro quando resolve falhar.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O caso do timestamp com fuso horário que me custou duas horas
Eu tive um problema específico recentemente. Estava escrevendo testes para um módulo que gerava relatórios com datas formatadas em UTC. O teste funcionava perfeitamente na minha máquina, que estava no fuso horário de Brasília. Quando foi deployado para o ambiente de staging, que rodava num container com timezone UTC configurado de outra forma, todos os testes de formatação de data quebraram. Dois testes. Dois horários diferentes. Dois formatos de string diferentes. A solução foi injetar uma dependência de data/hora via interface, em vez de chamar new Date() ou DateTime.Now diretamente no código testável. Assim eu podia passar timestamps fixos para o teste e garantir que o resultado seria sempre o mesmo, independente do ambiente. Pequeno ajuste, eliminou toda a aleatoriedade.
Mocks versus stubs: a diferença que separa quem sabe do quem acha que sabe
Muita gente usa mocks como se fossem tudo. Mock não é sinônimo de stub. Um stub responde com valores pré-definidos quando interpelado. Um mock verifica interações — se um método foi chamado, com quais argumentos, quantas vezes. Usar mock onde bastaria stub é acoplamento excessivo ao framework de teste. Quando você atualiza a versão da biblioteca, os mocks que verificam ordem de chamada quebram por capricho do framework, não por bug no seu código. Uma regra prática que funciona: use stubs para dados de entrada e saída. Use mocks apenas quando precisar validar que uma interação secundária ocorreu, como enviar um evento ou registrar um log. E mesmo nesse caso, prefira interfaces do que mocks gerados dinamicamente.
O custo real que ninguém calcula
Testes unitários exigem investimento inicial. Para cada linha de código produção, considere dedicar entre 30% e 50% do tempo em testes, dependendo da criticidade do domínio. Em sistemas financeiros ou de saúde, essa proporção sobe. Em protótipos internos que vão ser descartados em duas semanas, não faz sentido escrever teste algum. O coverage por si só é métrica inútil. Ter 95% de cobertura não significa que seu código está seguro. Significa que 95% das linhas foram executadas durante os testes. Linhas que podem estar sendo executadas com dados que nunca representam um edge case real. Eu já vi projetos com 98% de cobertura onde a principal função de cálculo tinha um bug óbvio que ninguém testou porque o fluxo de código que o contém nunca era alcançado com os dados de entrada usados.
Quando testes unitários simplesmente não resolvem
Testes unitários não detectam problemas de performance em produção, não validam layouts de UI, não garantem que a integração entre dois microserviços funciona como esperado. Eles não substituem testes de contrato, testes de carga, nem testes end-to-end. Cada camada do teste cobre um tipo diferente de risco. Ignorar isso por achar que testes unitários são suficientes é ingenuidade técnica disfarçada de praticidade. A cobertura ideal não é um número. É a combinação certa de testes em cada nível do pyramid — unitários na base, integracionais no meio, end-to-end no topo — focando nos comportamentos que realmente importam para o usuário final.
