TDD e estimativas: como testes impactam o planning
Time que pratica TDD estima diferente de time que não pratica — e os números são significativamente maiores. Não porque TDD seja mais lento, mas porque ele expõe complexidades que a codificação sem testes esconde.
O custo real de uma feature
Quando alguém pergunta “quanto custa implementar login com OAuth?”, a resposta ingênua considera:
- Criar formulário
- Integrar com provider OAuth
- Salvar sessão
A resposta realista (com TDD) considera:
- Testes do formulário (inputs, validação, loading states)
- Testes da integração (success, error, timeout)
- Testes de sessão (criação, expiração, refresh)
- Mock do provider para testes
- Edge cases (usuário existente, dados faltando)
O resultado: o que parecia 5 pontos vira 8.
TDD aumenta ou diminui estimativas?
Curto prazo: aumenta
Escrever testes antes do código leva mais tempo inicial. As estimativas refletem isso.
Longo prazo: diminui
- Menos bugs = menos retrabalho não-estimado
- Refatoração segura = mudanças não introduzem regressões
- Documentação viva = testes documentam o comportamento esperado
- Onboarding mais rápido = novos membros entendem código pelos testes
Incluir testes na Definition of Done
Se sua DoD inclui testes (e deveria), as estimativas devem incluir o esforço de testar:
“Essa feature de CRUD precisa de: testes unitários do serviço, testes de integração do controller, testes E2E do fluxo. Tudo isso está nos 8 pontos.”
O paradoxo do time sem testes
Times que não escrevem testes estimam menos porque:
- Não contam o tempo de testes (que vão precisar fazer depois)
- Não contam o tempo de debugging de bugs que surgem
O resultado é uma falsa eficiência: “fizemos em 3 dias” (mas gastamos 2 dias corrigindo bugs).
Estimando testes separadamente
Alguns times separam estimativa de feature e estimativa de teste:
| Item | Pontos de Feature | Pontos de Teste | Total |
|---|---|---|---|
| Login OAuth | 5 | 3 | 8 |
| Página de perfil | 3 | 2 | 5 |
| Export PDF | 5 | 5 | 10 |
Isso torna visível o custo de testabilidade. Se os pontos de teste são consistentemente altos, pode indicar código difícil de testar (dívida técnica).
Benchmarks por tipo de teste
Regra prática para distribuição de esforço:
- Testes unitários: 30-40% do esforço total
- Testes de integração: 20-30% do esforço total
- Testes E2E: 20-30% do esforço total
- Testes manuais/exploratórios: 10-20% do esforço total
TDD e Planning Poker
No Planning Poker com TDD:
- Vote pelo esforço total (feature + testes)
- Se alguém vota mais alto, pode estar pensando nos testes que outros esquecem
- “Isso é 5 pontos sem testes, mas com testes completos é 8” é uma discussão válida
Conclusão
Times com TDD estimam mais alto mas entregam mais previsivelmente porque as estimativas incluem o trabalho real completo. Se sua equipe não inclui testes nas estimativas, está sistematicamente subestimando — e a conta vem em bugs e retrabalho.