8 min leitura • Guide 832 of 877
Workflow de Desenvolvimento Orientado a Testes
Testes dirigem o design. O GitScrum ajuda equipes a rastrear adoção de TDD e medir o impacto de práticas test-first na qualidade e velocidade.
Fundamentos do TDD
O Ciclo Red-Green-Refactor
CICLO TDD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ O CICLO: │
│ ──────── │
│ │
│ ┌─────────────────────────────────────┐ │
│ │ │ │
│ │ ┌────────┐ │ │
│ │ │ RED │ Escreva teste que falha│ │
│ │ └───┬────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌────────┐ │ │
│ │ │ GREEN │ Faça passar │ │
│ │ └───┬────┘ (código mínimo) │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌────────┐ │ │
│ └────┤REFACTOR│ Melhore design │ │
│ └────────┘ (testes ainda passam) │ │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PASSO 1 - RED: │
│ Escreva um teste para comportamento que não existe ainda │
│ Execute → Falha (prova que teste funciona) │
│ │
│ PASSO 2 - GREEN: │
│ Escreva código suficiente para passar o teste │
│ Não over-engineer, não otimize │
│ Apenas faça funcionar │
│ │
│ PASSO 3 - REFACTOR: │
│ Agora melhore o código │
│ Remova duplicação, clarifique nomes, melhore design │
│ Testes garantem que você não quebrou nada │
│ │
│ REPITA para cada pequeno pedaço de comportamento │
└─────────────────────────────────────────────────────────────┘
Exemplo de Workflow
TDD na Prática
EXEMPLO TDD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FEATURE: Calcular total do pedido com desconto │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PASSO 1 - RED (Escreva teste que falha): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ test('calcula total com 10% desconto', () => { ││
│ │ const pedido = new Pedido([ ││
│ │ { preco: 100 }, ││
│ │ { preco: 50 } ││
│ │ ]); ││
│ │ pedido.aplicarDesconto(0.1); ││
│ │ expect(pedido.total()).toBe(135); ││
│ │ }); ││
│ │ ││
│ │ EXECUTA → ❌ FALHA (Pedido não existe) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PASSO 2 - GREEN (Faça passar): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ class Pedido { ││
│ │ constructor(items) { ││
│ │ this.items = items; ││
│ │ this.desconto = 0; ││
│ │ } ││
│ │ ││
│ │ aplicarDesconto(taxa) { ││
│ │ this.desconto = taxa; ││
│ │ } ││
│ │ ││
│ │ total() { ││
│ │ const subtotal = this.items.reduce( ││
│ │ (soma, item) => soma + item.preco, 0 ││
│ │ ); ││
│ │ return subtotal * (1 - this.desconto); ││
│ │ } ││
│ │ } ││
│ │ ││
│ │ EXECUTA → ✅ PASSA ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PASSO 3 - REFACTOR (Melhore): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Extrair cálculo de subtotal ││
│ │ • Adicionar validação ││
│ │ • Melhorar nomes ││
│ │ • Executar testes → Ainda passando ✅ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRÓXIMO: Escrever outro teste para próximo comportamento │
│ (ex: desconto máximo, preços negativos, etc.) │
└─────────────────────────────────────────────────────────────┘
Benefícios
Vantagens do TDD
BENEFÍCIOS DO TDD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DESIGN MELHOR: │
│ ────────────── │
│ • Código naturalmente modular (testável = modular) │
│ • Interfaces pensadas antes da implementação │
│ • Menos acoplamento │
│ • Mais fácil de refatorar │
│ │
│ MENOS BUGS: │
│ ─────────── │
│ • Captura bugs no momento da escrita │
│ • Alta cobertura de teste por padrão │
│ • Regressões detectadas imediatamente │
│ • Comportamento documentado em testes │
│ │
│ DESENVOLVIMENTO MAIS RÁPIDO (longo prazo): │
│ ────────────────────────────────────────── │
│ • Menos tempo debugando │
│ • Refatoração segura │
│ • Confiança para mudar código │
│ • Feedback instantâneo │
│ │
│ DOCUMENTAÇÃO: │
│ ───────────── │
│ • Testes são especificações executáveis │
│ • Sempre atualizada (senão falha) │
│ • Mostra como usar o código │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CUSTO INICIAL vs BENEFÍCIO: │
│ │
│ Tempo │ ╱ Sem TDD │
│ │ ╱─── │
│ │ ╱─── │
│ │ ╱─── │
│ │ ╱───────────────────── Com TDD │
│ │ ╱ │
│ └────────────────────────────────→ Meses │
│ │
│ TDD custa mais no início, economiza depois │
└─────────────────────────────────────────────────────────────┘
Princípios Chave
Regras do TDD
REGRAS DO TDD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REGRA 1: ESCREVA TESTE ANTES DO CÓDIGO │
│ ───────────────────────────────────────── │
│ Nunca escreva código de produção sem um teste que falha │
│ │
│ REGRA 2: APENAS UM TESTE QUE FALHA POR VEZ │
│ ────────────────────────────────────────── │
│ Não escreva mais testes até o atual passar │
│ │
│ REGRA 3: CÓDIGO MÍNIMO PARA PASSAR │
│ ────────────────────────────────── │
│ Escreva o código mais simples que faz o teste passar │
│ Não antecipe, não over-engineer │
│ │
│ REGRA 4: REFATORE SÓ COM TESTES VERDES │
│ ────────────────────────────────────── │
│ Melhore código apenas quando todos testes passam │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ BOAS PRÁTICAS: │
│ │
│ ✓ Ciclos curtos (minutos, não horas) │
│ ✓ Testes legíveis como especificação │
│ ✓ Um assert por teste (geralmente) │
│ ✓ Nomes descritivos de teste │
│ ✓ Independência entre testes │
│ │
│ ANTI-PADRÕES: │
│ │
│ ✗ Escrever vários testes antes do código │
│ ✗ Código "extra" que não é testado │
│ ✗ Pular etapa de refatoração │
│ ✗ Testes que testam implementação, não comportamento │
└─────────────────────────────────────────────────────────────┘
Adotando TDD na Equipe
Estratégia de Adoção
ADOTANDO TDD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FASE 1: PILOTO (2-4 semanas) │
│ ──────────────────────────── │
│ • 1-2 desenvolvedores experimentam │
│ • Em código novo, não legado │
│ • Compartilham experiência com equipe │
│ │
│ FASE 2: EXPANSÃO (1-2 meses) │
│ ─────────────────────────── │
│ • Mais membros adotam │
│ • Pair programming para transferência │
│ • Estabelecer práticas da equipe │
│ │
│ FASE 3: NORMALIZAÇÃO (ongoing) │
│ ───────────────────────────── │
│ • TDD é padrão para código novo │
│ • Incluído em code review │
│ • Parte da definição de done │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RESISTÊNCIA COMUM: │
│ │
│ "Não temos tempo" │
│ → TDD economiza tempo de debug depois │
│ │
│ "É muito difícil" │
│ → Começa pequeno, com pair programming │
│ │
│ "Meu código não é testável" │
│ → TDD força código testável = melhor design │
│ │
│ "Não funciona para UI" │
│ → Separe lógica de UI, teste lógica │
└─────────────────────────────────────────────────────────────┘
Métricas de TDD
O Que Medir
MEDINDO SUCESSO DO TDD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MÉTRICAS DIRETAS: │
│ ──────────────── │
│ │
│ • Cobertura de teste (meta: > 80% para lógica de negócio)│
│ • % de código escrito com TDD │
│ • Tempo do ciclo red-green-refactor │
│ │
│ MÉTRICAS DE QUALIDADE: │
│ ────────────────────── │
│ │
│ • Bugs em produção (deve diminuir) │
│ • Bugs de regressão (deve diminuir) │
│ • Tempo de debug (deve diminuir) │
│ │
│ MÉTRICAS DE PRODUTIVIDADE: │
│ ────────────────────────── │
│ │
│ • Lead time (pode aumentar inicialmente, depois diminui) │
│ • Confiança para refatorar (survey da equipe) │
│ • Velocidade de longo prazo (deve aumentar) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CUIDADO: │
│ • Não force 100% de cobertura em tudo │
│ • Cobertura alta ≠ testes bons │
│ • Qualidade dos testes importa mais que quantidade │
└─────────────────────────────────────────────────────────────┘