Testes que pegam a quebra antes do usuário

Para quem é

Para empresas em que cada correção quebra outra coisa e ninguém confia em mexer no código.

O que resolve

• Corrigir um erro cria outro, que só aparece em produção.
• Uma mudança na API quebra o app ou a integração de um parceiro, e ninguém foi avisado.
• Os testes que existem falham sem motivo claro, então ninguém confia no resultado.
• Testar uma versão depende de alguém clicar em tudo à mão antes de publicar.

O que fazemos

Testes de unidade

As regras de negócio testadas isoladamente, inclusive os casos de borda que mais causam erro.

Testes de integração

Banco de dados, filas e serviços externos de verdade, subidos em contêineres durante o teste.

Testes de contrato

Quem consome e quem fornece uma API combinam o formato; uma quebra é detectada antes da publicação.

Cenários brasileiros

Pagamento repetido, recusa e tempo esgotado em fluxos de Pix e de nota fiscal.

Dados de teste

Dados fictícios e reproduzíveis, criados pelo próprio teste, sem cópia de dados reais.

Testes instáveis

Testes que falham ao acaso são investigados e consertados, e não desligados.

O que você recebe

• Suíte de testes de unidade, integração e contrato no seu repositório
• Testes rodando no pipeline a cada mudança, com bloqueio em caso de falha
• Relatório do que está coberto e do que ainda não está
• Estratégia de dados de teste documentada
• Guia para a sua equipe escrever novos testes no mesmo padrão

Como fazemos

1. Mapa de risco

   Quais fluxos mais doem quando quebram e quais já têm algum teste.

2. Base de testes

   Ferramentas, dados de teste e ambiente com contêineres preparados para a equipe.

3. Fluxos críticos

   Primeiro os testes dos fluxos de maior risco, depois o restante.

4. Contratos

   Contratos entre o back-end, os apps e as integrações, verificados a cada versão.

5. Pipeline

   Os testes passam a decidir se uma versão segue ou para.

Exemplos de tecnologia

• Pact
• Testcontainers
• JUnit
• pytest
• Jest
• WireMock
• Playwright