TL;DR: Test-Driven Development (TDD) é uma forma de desenvolver software começando pelos testes. O ciclo é simples: RED (escreva um teste que falha), GREEN (faça o mínimo para passar) e REFACTOR (melhore o código sem quebrar comportamento). Isso reduz retrabalho, melhora design e aumenta previsibilidade de entrega.
- O que é Test-Driven Development (TDD)
- Como funciona o ciclo RED-GREEN-REFACTOR
- 1) RED escrever um teste que falha
- 2) GREEN fazer o mínimo para passar
- 3) REFACTOR melhorar sem alterar comportamento
- TDD aumenta o tempo de desenvolvimento?
- TDD substitui QA manual?
- Qual a diferença entre TDD e testar depois de implementar?
Neste guia:
- O que é TDD
- Ciclo RED-GREEN-REFACTOR
- Exemplo real no mundo de produto
- Checklist de adoção em 30 dias
- Erros comuns ao aplicar TDD
- FAQ
O que é Test-Driven Development (TDD)
Test-Driven Development (também chamado de desenvolvimento orientado a testes) é uma prática em que o time define o comportamento esperado antes de implementar a solução. Em vez de “codar e depois testar”, você descreve o resultado esperado em teste automatizado e usa esse teste para guiar o design.
Este artigo é para analistas de requisitos, tech leads, devs e product managers que querem reduzir bugs em produção e traduzir melhor regras de negócio em software. Na prática, TDD ajuda a transformar requisito em critério verificável, com feedback rápido a cada iteração.
Se você está estruturando base de testes, vale complementar com este conteúdo interno sobre testes automatizados de software.
Como funciona o ciclo RED-GREEN-REFACTOR
1) RED: escrever um teste que falha
Comece pelo menor comportamento possível. Exemplo: “deve impedir cadastro com e-mail inválido”. Rode o teste e confirme que ele falha. Esse passo evita implementar funcionalidade ambígua e força clareza de escopo.
2) GREEN: fazer o mínimo para passar
Implemente a menor mudança possível para tornar o teste verde. Nada de antecipar cenários futuros aqui. O objetivo é validar rapidamente se a regra de negócio foi atendida.
3) REFACTOR: melhorar sem alterar comportamento
Com os testes verdes, melhore nomes, extraia funções e reduza duplicação. O teste protege o comportamento durante a refatoração. Esse passo conversa diretamente com boas práticas de padrões de projeto.
Exemplo real: endpoint de cadastro de usuário
Cenário: um squad precisava reduzir incidentes no endpoint
POST /usuarios. Antes, a validação de regras de e-mail e senha acontecia de forma inconsistente entre controller e service.
