

Junior Alves
Senior Developer
Foto: Unsplash
5 de maio de 2025 • 3 minutos de leitura
Programar é Resolver Problemas, certo?
O que o TDD tem em comum com o método de resolução de problemas de George Pólya?
Introdução
Você já sabe: no fundo, programar é só mais uma forma de resolver problemas.
Agora imagina se um matemático do século passado tivesse criado um método que, sem querer, antecipou uma das práticas mais queridas por devs modernos: o TDD. Pois é exatamente isso que a gente vai ver aqui — como o método de George Pólya e o Test-Driven Development têm muito mais em comum do que parece.
TDD e o método de George Pólya: uma conexão atemporal
George Pólya foi um matemático húngaro do século XX, conhecido por sua didática e por suas contribuições à resolução de problemas, combinatória e teoria das probabilidades. Seu livro “How to Solve It” (1945) se tornou um clássico da educação matemática, traduzido para mais de 20 idiomas e amplamente usado até hoje.
Nesse livro, Pólya propôs um método simples e poderoso para resolver problemas, composto por 4 etapas:
- Entendimento
- Planejamento
- Execução
- Revisão
"If you can't solve a problem, then there is an easier problem you can solve: find it." — George Pólya
Agora, vamos conectar esse método à prática do TDD (Test-Driven Development).
O que é TDD?
TDD, ou Desenvolvimento Orientado a Testes, é uma técnica de desenvolvimento de software popularizada no início dos anos 2000 por Kent Beck, um dos criadores do XP (Extreme Programming). A ideia central é escrever os testes antes do código de produção.
O ciclo do TDD segue três passos bem definidos:
🔴 Red – Escrever um teste que falha
🟢 Green – Escrever o código mínimo para passar o teste
🔵 Refactor – Refatorar o código mantendo os testes verdes
“Test-first programming is not about testing. It’s about designing software.” — Kent Beck
“TDD gives you confidence to make changes. It’s less about finding bugs, and more about enabling change.” — Martin Fowler
TDD vs Método de Pólya: um paralelo que faz sentido
Vamos aprofundar nessa comparação etapa por etapa:
1. Entendimento (Red)
Assim como Pólya nos convida a compreender o problema antes de tentar resolvê-lo, no TDD começamos escrevendo um teste. Para isso, precisamos entender claramente a regra de negócio, os requisitos e os comportamentos esperados.
O teste falha — e deve falhar — pois ainda não há solução. Mas ele nos obriga a pensar antes de codar.
2. Planejamento (também Red)
Aqui, Pólya sugere pensar em estratégias para resolver o problema. No TDD, ao escrever o teste, já estamos planejando a interface, a responsabilidade e o comportamento esperado do código. Essa etapa exige clareza de intenção e foco no objetivo.
3. Execução (Green)
É hora de colocar o plano em ação. No TDD, isso é escrever o código de produção mínimo para fazer o teste passar. Nem mais, nem menos.
Essa limitação imposta pelo TDD nos força a manter o código simples e direto ao ponto — um reflexo da objetividade defendida por Pólya.
4. Revisão (Refactor)
Com a solução funcionando, Pólya recomenda revisar o processo, analisar a clareza, procurar por melhorias e aprender com o caminho percorrido.
No TDD, esse é o momento de refatorar: melhorar nomes, abstrações e performance, garantindo que os testes ainda passam e que o sistema evolui com qualidade.
Conclusão
Neste post, exploramos a relação entre dois mundos:
A resolução de problemas matemáticos, ensinada por George Pólya há quase 80 anos.
E o TDD, uma técnica moderna de desenvolvimento de software.
Vimos que, embora distantes no tempo e na forma, ambos compartilham uma mesma essência: pensar antes de agir, agir com propósito e revisar com cuidado.
Curtiu? Compartilhe esse post: