Testes no pipeline: o que rodar em cada estágio sem travar a entrega

Existe um equilíbrio difícil no CI. De um lado, o pipeline precisa dar confiança suficiente para que ninguém tenha medo de fazer deploy. Do outro, ele precisa ser rápido o bastante para que as pessoas o usem com frequência. Errar para um lado produz entregas assustadoras; errar para o outro produz um time que ignora o pipeline.

A saída não é escolher um extremo. É distribuir os testes pelos estágios de acordo com o que cada um custa e com o que cada um prova.

A pergunta que organiza tudo

Para cada teste, duas coisas: quanto ele custa em tempo e que classe de erro ele pega. Testes caros que pegam erros raros não pertencem ao caminho crítico do commit.

Isso produz naturalmente a distribuição:

O princípio: quanto mais cedo o estágio, mais rápido ele precisa ser, porque é o que a pessoa está esperando na tela.

Commit: retorno rápido acima de tudo

O que roda aqui existe para responder uma pergunta em minutos: "eu quebrei alguma coisa óbvia?".

• Lint e formatação. Segundos. Evita discussão de estilo em revisão.
• Verificação de tipos, onde a linguagem oferece. Pega uma classe inteira de erro antes de qualquer teste.
• Testes unitários. Sem banco, sem rede, sem sistema de arquivos. Se precisa subir container, não é unitário — é de integração e pertence ao estágio seguinte.
• Build. Se não compila, nada mais importa.

Meta: menos de 10 minutos. Se passar disso, paralelize os unitários antes de qualquer outra otimização.

Pull request: onde mora a confiança

Aqui entram os testes que provam que as partes conversam.

• Testes de integração. Com dependências reais em container efêmero — banco de verdade, fila de verdade. Banco falso testa o seu falso, não o comportamento real; a diferença aparece em transação, tipo de dado e comportamento concorrente.
• Testes de contrato, entre serviços que se comunicam. Garantem que uma mudança de API não quebra quem consome, sem precisar subir o sistema inteiro. Em arquitetura distribuída, é o teste de melhor retorno por esforço.
• Análise estática de segurança no código alterado.
• Análise de dependências, procurando vulnerabilidade conhecida em biblioteca.
• Scan da imagem de container.
• Migração de banco aplicada contra uma cópia do esquema real, para pegar migração que falha em produção.

O ponto mais importante desta lista: use dependências reais em container efêmero. É a prática que mais aumenta a confiança do pipeline, e hoje o custo dela é baixo.

Pré-produção: o caminho crítico do usuário

Testes ponta a ponta são caros, lentos e frágeis. Também são os únicos que provam que o sistema funciona de verdade.

A disciplina que os torna sustentáveis é a restrição de escopo: poucos, sobre os fluxos que geram dinheiro ou impedem o uso do produto. Login, compra, cadastro, a operação central do seu negócio. Dez a vinte cenários, não trezentos.

Junto com eles:

• Teste de fumaça após o deploy no ambiente, verificando se o serviço subiu e responde.
• Migração de banco contra volume realista, para medir tempo — migração que leva 40 minutos em produção precisa ser descoberta aqui.
• Verificação de configuração: variáveis presentes, segredos acessíveis, dependências alcançáveis.

Pós-deploy: o teste que roda em produção

Nenhum ambiente reproduz produção. Por isso a verificação continua depois do deploy:

• Fumaça em produção, com transação sintética exercitando o caminho crítico.
• Janela de observação com alerta reforçado sobre taxa de erro e latência.
• Rollback automático se os indicadores degradarem além do limite definido.

Esse último item é o que fecha o ciclo. Ele exige que os critérios estejam escritos antes do deploy — e é o que transforma monitoramento em rede de proteção em vez de relatório.

Testes agendados: o que não cabe no caminho

Alguns testes são valiosos e lentos demais para bloquear entrega:

• Carga e estresse, semanal ou antes de evento de pico.
• Matriz completa de versões de sistema, navegador ou banco.
• Verificação de vulnerabilidade em toda a base, não só no alterado — vulnerabilidade nova é descoberta em código que não mudou.
• Teste de restauração de backup, que é um teste como qualquer outro e quase nunca é tratado assim.

Eles rodam à noite e geram tarefa, não bloqueiam merge. Com uma condição: alguém precisa olhar. Teste agendado que falha há três semanas sem ninguém reparar é pior que não ter, porque dá falsa sensação de cobertura.

O teste instável: o inimigo principal

Teste que falha aleatoriamente causa mais dano que teste lento. Ele ensina o time a reexecutar o pipeline sem ler a falha — e no dia em que a falha for real, ela será ignorada do mesmo jeito.

Não conviva. O tratamento:

1. Identifique. Registre reexecuções por teste; os instáveis aparecem sozinhos na estatística.
2. Quarentena imediata. Tire do caminho crítico para ele parar de causar dano. Isso é contenção, não solução.
3. Prazo para corrigir. Quarentena sem prazo vira cemitério, e o teste perde valor.
4. Corrija a causa. Quase sempre é espera por tempo fixo em vez de condição, dependência de ordem de execução, estado compartilhado entre testes ou dado que não é recriado.
5. Se não vale corrigir, apague. Teste em que ninguém confia não protege nada e custa tempo.

O item 4 merece nota: espera por tempo fixo é a causa número um. Substituir por espera ativa até uma condição resolve a maioria dos casos e ainda deixa o teste mais rápido.

Cobertura: use como sinal, não como meta

Cobertura de código mede o que foi executado, não o que foi verificado. É possível ter 90% de cobertura com testes que não afirmam nada.

Como usar bem:

• Como sinal: cobertura caindo em código novo indica que alguém entregou sem teste. Isso é acionável.
• Como mapa: áreas críticas com cobertura baixa são candidatas a investimento.
• Não como meta numérica global. Meta de percentual produz testes escritos para o medidor.

Melhor que percentual global: exigir que o código alterado venha coberto. Foca o esforço onde o risco está e não obriga ninguém a cobrir código legado que ninguém toca.

O portão: o que impede o merge

Precisa estar explícito e ser pequeno:

• Lint e tipos passando.
• Unitários passando.
• Build bem-sucedido.
• Integração e contrato passando.
• Sem vulnerabilidade de severidade alta introduzida.
• Cobertura do código alterado dentro do acordado.
• Revisão aprovada.

E o que não deveria bloquear: teste de carga, matriz completa, resultado de teste agendado, cobertura global. São informações, não portões.

Erros comuns

• Rodar a suíte inteira, inclusive ponta a ponta, a cada commit.
• Retorno de mais de 20 minutos no commit, e o time deixa de integrar com frequência.
• Testes de integração com dependência falsa em vez de container real.
• Centenas de testes ponta a ponta, lentos e frágeis.
• Conviver com teste instável e reexecutar o pipeline por hábito.
• Espera por tempo fixo em vez de espera por condição.
• Quarentena sem prazo, virando cemitério.
• Meta de cobertura global gerando teste sem asserção.
• Teste agendado falhando há semanas sem ninguém olhar.
• Não rodar nada depois do deploy em produção.
• Critério de rollback definido no calor do incidente.
• Migração de banco só testada com base pequena.

Onde a Solvefy/Cloud entra

Reorganizar a suíte pelos estágios é um dos ajustes de maior efeito no ritmo de entrega — e raramente exige escrever teste novo, apenas mover e paralelizar o que já existe. Fazemos esse desenho com o seu time: definição dos estágios e dos portões, dependências reais em container efêmero, testes de contrato entre serviços, fumaça pós-deploy com rollback automático por critério escrito, rastreamento de testes instáveis e a rotina que impede que eles voltem. Trabalhamos com GitHub Actions, GitLab CI e Jenkins.

Seu time confia no pipeline ou reexecuta até passar? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.