Programar é Resolver Problemas, certo?

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:

1. Entendimento
2. Planejamento
3. Execução
4. 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.