TDD — Test-Driven Development — inverte a ordem intuitiva: você escreve o teste antes do código. Parece contraintuitivo, mas é uma das técnicas que mais melhora o design e a confiança no que se entrega.

O ciclo: Red, Green, Refactor

1. Red: escreva um teste que falha — ele descreve o comportamento que ainda não existe.
2. Green: escreva o mínimo de código para o teste passar. Sem firula.
3. Refactor: melhore o código com a rede de segurança do teste verde.

// 1. Red — o teste falha porque a função não existe
test('soma dois números', () => {
  expect(soma(2, 3)).toBe(5);
});

// 2. Green — o mínimo para passar
function soma(a, b) { return a + b; }

// 3. Refactor — agora com segurança para evoluir

Por que funciona

• Design guiado pelo uso: você projeta a API pensando em quem a chama.
• Cobertura natural: o código nasce testado, sem "depois eu escrevo o teste".
• Feedback curto: erros aparecem em segundos, não em produção.
• Documentação viva: os testes descrevem o comportamento esperado.

TDD não é sobre testes — é sobre design. Os testes são o efeito colateral feliz.

Quando pesar a mão

TDD brilha em lógica de negócio e regras complexas. Para protótipos descartáveis ou código de exploração, pode ser exagero. O segredo é usar a ferramenta certa para o contexto — não transformar TDD em dogma.

Conclusão

Praticar o ciclo red-green-refactor treina o time a pensar em comportamento e a manter o código sempre sob uma rede de segurança. É um investimento que se paga na primeira refatoração tranquila.

TDD — Test-Driven Development — flips the intuitive order: you write the test before the code. It sounds counterintuitive, but it is one of the techniques that most improves design and confidence in what you ship.

The cycle: Red, Green, Refactor

1. Red: write a failing test — it describes behavior that doesn't exist yet.
2. Green: write the minimum code to make the test pass. No frills.
3. Refactor: improve the code with the safety net of a green test.

// 1. Red — the test fails because the function doesn't exist
test('adds two numbers', () => {
  expect(soma(2, 3)).toBe(5);
});

// 2. Green — the minimum to pass
function soma(a, b) { return a + b; }

// 3. Refactor — now safe to evolve

Why it works

• Usage-driven design: you design the API thinking about whoever calls it.
• Natural coverage: the code is born tested, with no "I'll write the test later".
• Short feedback: errors show up in seconds, not in production.
• Living documentation: the tests describe the expected behavior.

TDD isn't about testing — it's about design. The tests are the happy side effect.

When to go easy

TDD shines in business logic and complex rules. For throwaway prototypes or exploratory code, it can be overkill. The key is to use the right tool for the context — not to turn TDD into dogma.

Conclusion

Practicing the red-green-refactor cycle trains the team to think in terms of behavior and to keep the code always under a safety net. It's an investment that pays off with the first painless refactoring.