GitHub

A maioria dos times não tem um problema de "falta de testes". Tem um problema de testes mal arquitetados.

Eles começam bem-intencionados. Alguém escreve um teste, depois outro, e em poucos meses existe uma suíte com centenas de casos. O problema aparece quando essa suíte começa a demorar vinte minutos para rodar, quebra por qualquer mudança trivial e ninguém mais confia no resultado vermelho. A reação natural é desligar o teste "que sempre falha". A partir daí, a suíte vira teatro.

Este guia é direto: antes de discutir qual ferramenta usar, decida a arquitetura dos seus testes. É essa decisão que separa uma suíte que protege o time de uma que o atrasa.

Por que arquitetura vem antes de cobertura

Cobertura é uma métrica fácil de medir e fácil de enganar. Dá para ter 90% de cobertura testando getters e setters, sem proteger nenhuma regra de negócio que importa.

O que de fato sustenta velocidade é a forma como os testes estão organizados: o que cada nível testa, quão rápido rodam, quão isolados são e quão claramente apontam o que quebrou. Isso é decisão de arquitetura, não de quantidade.

Penso nisso como infraestrutura. Você não escala um sistema empilhando servidores aleatoriamente; define camadas, responsabilidades e contratos. Com testes é igual. Sem desenho, a suíte cresce como dívida, não como ativo.

A pirâmide ainda é o ponto de partida

A pirâmide de testes continua sendo o modelo mental mais útil para começar. A base são testes de unidade: muitos, rápidos, isolados. No meio, testes de integração, que verificam se as peças conversam. No topo, poucos testes de ponta a ponta, que exercitam o fluxo do usuário.

A regra prática é simples. Quanto mais alto na pirâmide, mais caro e mais lento o teste, e mais frágil. Por isso o topo deve ser estreito. Um time que inverte a pirâmide, com dezenas de testes de interface e poucos de unidade, terá uma suíte lenta e instável.

O erro mais comum aqui é tratar a pirâmide como dogma. Em sistemas muito orientados a integração, APIs que orquestram serviços, por exemplo, faz sentido engrossar a camada de integração. O formato importa menos que o princípio: empurre a verificação para o nível mais barato que ainda dá confiança.

Decisões que definem a arquitetura

Algumas escolhas têm impacto desproporcional na saúde da suíte. Vale resolvê-las cedo.

A primeira é o que isolar. Testes de unidade devem rodar sem banco, sem rede, sem relógio real. Quando você precisa subir meio sistema para testar uma função, o problema não é o teste, é o acoplamento do código. O teste só está denunciando.

A segunda é como lidar com dependências externas. Mocks e stubs aceleram, mas mentem: testam o que você acha que a dependência faz, não o que ela faz. Por isso eu reservo testes de integração reais para as fronteiras críticas, pagamento, autenticação, persistência, e uso dublês com parcimônia no resto.

A terceira é onde os testes moram. Mantenha-os perto do código que verificam. Suítes em repositórios separados quase sempre apodrecem, porque mudam em ritmo diferente do código de produção.

Velocidade é uma feature da suíte

Uma suíte lenta é uma suíte que será ignorada. Se rodar tudo leva meia hora, o desenvolvedor vai rodar só uma parte, ou nada, e descobrir o problema só na esteira de CI, tarde demais.

A meta prática é que a camada de unidade rode em segundos, localmente, durante o desenvolvimento. Isso exige disciplina: testes paralelizáveis, sem dependência de estado compartilhado, sem sleep para "esperar" alguma coisa. Esperas fixas são a maior fonte de lentidão e de instabilidade em suítes reais.

No CI, separe por estágio. Roda unidade primeiro, falha rápido, e só então parte para integração e ponta a ponta. Não faz sentido gastar dez minutos num teste de interface se uma regra básica já está quebrada.

O inimigo real: testes intermitentes

Se há um único item que destrói a confiança numa suíte, é o teste que às vezes passa e às vezes falha sem que nada tenha mudado. Ele é pior do que não ter teste, porque ensina o time a ignorar o vermelho.

Testes intermitentes quase sempre nascem de três fontes: dependência de tempo, dependência de ordem de execução e estado compartilhado entre casos. Resolver isso é trabalho de arquitetura, não de paciência. Cada teste deve montar e limpar seu próprio cenário, sem assumir nada sobre o que rodou antes.

Eu trato teste intermitente como incidente, não como ruído. Quando um aparece, ou conserto, ou removo. Manter um teste não confiável na suíte contamina todos os outros.

Quem garante a qualidade da suíte

Aqui entra a visão de gestão que muitos times ignoram. Código de teste é código. Ele precisa de revisão, refatoração e dono. Uma suíte abandonada degrada na mesma velocidade que qualquer outro sistema sem manutenção.

Em times que lidero, a regra é que o teste faz parte da definição de pronto, não é uma tarefa separada empurrada para o fim da sprint. E a saúde da suíte (tempo de execução, taxa de falha intermitente) entra como métrica de engenharia, ao lado de outras que acompanhamos.

No contexto público e em produtos que lidam com dados sensíveis, isso ganha outro peso. Uma suíte confiável é parte do que te permite mudar um sistema crítico sem rezar para nada quebrar. Isso é governança, não capricho técnico.

Comece pequeno, mas comece com desenho

Se sua suíte ainda é pequena, este é o momento barato de acertar a arquitetura. Defina os níveis, estabeleça que testes de unidade não tocam infraestrutura, exija que cada teste seja isolado e trate velocidade como requisito.

Se a suíte já está grande e dolorida, não tente reescrever tudo. Pare de sangrar primeiro: elimine os intermitentes, separe os estágios no CI e proteja com testes novos só o que muda com frequência. O resto você melhora aos poucos.

Testes automatizados não existem para provar que o código funciona hoje. Existem para te dar coragem de mudá-lo amanhã. Uma boa arquitetura de testes é, no fundo, um seguro contra o medo de evoluir o sistema.

Se o seu time já tem testes mas perdeu a confiança neles, vale revisitar a arquitetura antes de escrever mais um caso. Tenho outros textos no blog sobre qualidade e engenharia de software, e se esse é um problema real na sua organização, é o tipo de conversa que rende.

Arquitetura de testes automatizados: um guia rápido para times que precisam de velocidade