7 min leitura • Guide 804 of 877
Estratégia de Automação de Testes
Testes automatizados permitem confiança e velocidade. O GitScrum integra com resultados de teste para mostrar status de qualidade junto com progresso de desenvolvimento.
Estratégia de Testes
Pirâmide de Testes
A PIRÂMIDE DE TESTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ /\ │
│ / \ │
│ / E2E\ ← Poucos (lentos, caros) │
│ / \ Manual + Automatizado │
│ /────────\ │
│ / \ │
│ / Integração \ ← Alguns (velocidade média)│
│ / \ API, testes de componente│
│ /────────────────\ │
│ / \ │
│ / Unitário \ ← Muitos (rápidos) │
│ / \ Nível de função │
│ /────────────────────────\ │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PROPORÇÃO RECOMENDADA: │
│ • 70% Testes unitários │
│ • 20% Testes de integração │
│ • 10% Testes E2E │
│ │
│ POR QUE ESTA PROPORÇÃO: │
│ ─────────────────────── │
│ TESTES UNITÁRIOS: │
│ • Rápidos (milissegundos cada) │
│ • Fáceis de manter │
│ • Identificam falhas exatamente │
│ • Rodam a cada commit │
│ │
│ TESTES DE INTEGRAÇÃO: │
│ • Testam interação de componentes │
│ • Capturam bugs de integração │
│ • Mais lentos que unitários │
│ │
│ TESTES E2E: │
│ • Jornada completa do usuário │
│ • Capturam issues do mundo real │
│ • Lentos e flaky │
│ • Caros para manter │
└─────────────────────────────────────────────────────────────┘
O Que Automatizar
DECISÃO DE AUTOMAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AUTOMATIZE SE: │
│ ────────────── │
│ ☑ Roda frequentemente (cada commit, cada deploy) │
│ ☑ Caminho crítico (login, checkout, features core) │
│ ☑ Repetitivo (mesmo teste, muitas variações de dados) │
│ ☑ Risco de regressão (quebrou antes, pode quebrar de novo)│
│ ☑ Demorado manualmente │
│ │
│ MANTENHA MANUAL SE: │
│ ───────────────── │
│ ☑ Exploratório (descobrir issues desconhecidas) │
│ ☑ Usabilidade/UX (precisa julgamento humano) │
│ ☑ Cenários raros (verificação única) │
│ ☑ Avaliação visual (qualidade de design) │
│ ☑ Setup complexo com baixo ROI │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ROADMAP DE AUTOMAÇÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ FASE 1: FUNDAÇÃO ││
│ │ • Setup de framework de teste unitário ││
│ │ • Pipeline CI rodando testes ││
│ │ • Smoke tests de caminho crítico ││
│ │ ││
│ │ FASE 2: COBERTURA CORE ││
│ │ • Testes unitários para lógica de negócio ││
│ │ • Testes de integração de API ││
│ │ • Testes E2E de happy path ││
│ │ ││
│ │ FASE 3: ABRANGENTE ││
│ │ • Cobertura de edge cases ││
│ │ • Testes de performance ││
│ │ • Testes de segurança ││
│ │ ││
│ │ FASE 4: OTIMIZAÇÃO ││
│ │ • Execução paralela de testes ││
│ │ • Gestão de dados de teste ││
│ │ • Eliminação de testes flaky ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Tipos de Teste
Por Camada
TIPOS DE TESTE POR CAMADA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TESTES UNITÁRIOS: │
│ ───────────────── │
│ Testam funções/métodos individuais │
│ Sem dependências externas (mock delas) │
│ Rápidos: milhares por minuto │
│ │
│ EXEMPLO: │
│ test('calcula desconto percentual', () => { │
│ expect(calcularDesconto(100, 0.1)).toBe(90); │
│ }); │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TESTES DE INTEGRAÇÃO: │
│ ───────────────────── │
│ Testam componentes trabalhando juntos │
│ Pode usar banco de dados de teste │
│ Chamadas API reais (para ambiente de teste) │
│ │
│ EXEMPLO: │
│ test('POST /pedidos cria pedido no banco', async () => { │
│ const response = await request(app) │
│ .post('/pedidos') │
│ .send({ items: [...] }); │
│ │
│ expect(response.status).toBe(201); │
│ const pedido = await Pedido.findById(response.body.id);│
│ expect(pedido).toBeDefined(); │
│ }); │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TESTES E2E: │
│ ─────────── │
│ Simulam usuário real no browser │
│ Ambiente completo │
│ Fluxos críticos de usuário │
│ │
│ EXEMPLO: │
│ test('usuário completa checkout', () => { │
│ cy.login(); │
│ cy.visit('/produtos/1'); │
│ cy.get('[data-testid=add-cart]').click(); │
│ cy.get('[data-testid=checkout]').click(); │
│ cy.contains('Pedido confirmado'); │
│ }); │
└─────────────────────────────────────────────────────────────┘
Manutenção de Testes
Mantendo Testes Saudáveis
MANUTENÇÃO DE SUITE DE TESTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRATE TESTES COMO CÓDIGO DE PRODUÇÃO: │
│ ────────────────────────────────────── │
│ │
│ REFATORE REGULARMENTE: │
│ • Extraia helpers comuns │
│ • Remova duplicação │
│ • Melhore nomes de testes │
│ • Simplifique setups │
│ │
│ DELETE TESTES OBSOLETOS: │
│ • Feature removida? Remova testes │
│ • Teste duplicado? Mantenha um │
│ • Teste sem valor? Remova │
│ │
│ CORRIJA TESTES FLAKY IMEDIATAMENTE: │
│ • Flaky = pior que não ter teste │
│ • Quarentena até corrigir │
│ • Corrija ou delete, nunca ignore │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REVISÃO TRIMESTRAL: │
│ ──────────────────── │
│ │
│ ☐ Testes ainda relevantes? │
│ ☐ Cobertura adequada em áreas críticas? │
│ ☐ Testes rodando rápido o suficiente? │
│ ☐ Taxa de flaky aceitável (< 1%)? │
│ ☐ Feedback útil quando falham? │
│ │
│ MÉTRICAS A ACOMPANHAR: │
│ │
│ • Tempo total de execução │
│ • Taxa de flaky │
│ • Cobertura por área │
│ • Bugs escapados (não pegos por testes) │
└─────────────────────────────────────────────────────────────┘
CI/CD Integration
Testes no Pipeline
TESTES NO PIPELINE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ COMMIT: │
│ ─────── │
│ Testes unitários (~5 min) │
│ ↓ │
│ Lint e análise estática │
│ ↓ │
│ MERGE REQUEST: │
│ ────────────── │
│ Testes unitários │
│ ↓ │
│ Testes de integração (~15 min) │
│ ↓ │
│ Cobertura mínima check │
│ ↓ │
│ MERGE TO MAIN: │
│ ────────────── │
│ Testes unitários │
│ ↓ │
│ Testes de integração │
│ ↓ │
│ Testes E2E (~30 min) │
│ ↓ │
│ Deploy para staging │
│ ↓ │
│ Smoke tests em staging │
│ ↓ │
│ DEPLOY PRODUÇÃO: │
│ ──────────────── │
│ Smoke tests │
│ ↓ │
│ Monitoring │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REGRAS: │
│ • Testes rápidos primeiro │
│ • Fail fast (não continue se básico falhou) │
│ • Feedback em < 10 min para PR │
│ • E2E só quando necessário (merge, deploy) │
└─────────────────────────────────────────────────────────────┘