Test-Driven Development.
Uma disciplina de desenvolvimento na qual você escreve um teste que falha antes do código que o faz passar e depois refatora — deixando os testes guiarem o design em ciclos curtos e enxutos.
##Intent
Conduza o design e verifique a corretude do código escrevendo um teste que falha para cada pequeno trecho de comportamento antes de escrever o código que o satisfaz, melhorando então o design enquanto os testes mantêm você seguro.
##Problem
Código escrito sem testes é arriscado de mudar: não há uma forma rápida de saber se uma edição quebrou algo. Testes escritos depois tendem a ser superficiais, moldados para se encaixar em um código que já pode ser difícil de testar, e raramente influenciam o design.
Sem uma função forçante, os designs também tendem a ficar emaranhados e difíceis de exercitar isoladamente.
##Solution
Trabalhe em um ciclo curto de Red-Green-Refactor (Vermelho-Verde-Refatorar):
- Vermelho — escreva um pequeno teste para o próximo trecho de comportamento e observe-o falhar.
- Verde — escreva o código mais simples que faz o teste passar, mesmo que seja feio.
- Refatorar — limpe o código (e os testes) agora que estão verdes, com a suíte protegendo contra regressões.
Repita em ciclos de poucos minutos. Como os testes vêm primeiro, o código é testável por construção e a suíte documenta o comportamento pretendido.
##Structure
- O ciclo — Vermelho → Verde → Refatorar, repetido continuamente.
- Lista de testes — a lista corrente de comportamentos ainda a cobrir.
- Arrange–Act–Assert — o formato de um teste de unidade focado.
- Unidade sob teste — a pequena fatia de comportamento que cada teste fixa.
##Applicability
- Use para código com lógica e ramificações reais, e para código de vida longa que mudará com frequência.
- Especialmente valioso onde um ciclo de feedback rápido e a segurança contra regressões importam.
- Menos adequado para spikes descartáveis ou trabalho exploratório de UI em que o design ainda está em definição.
##How to Implement
- Escolha o próximo pequeno comportamento da sua lista de testes.
- Escreva um teste que o verifique e execute a suíte para vê-lo falhar (vermelho).
- Escreva o código mínimo necessário para passar; execute a suíte (verde).
- Refatore o código de produção e de teste mantendo a suíte verde.
- Repita, acrescentando comportamentos à lista à medida que os descobre.
##Pros & Cons
- Alta cobertura de testes como subproduto, não como algo deixado para depois.
- O feedback rápido detecta regressões em segundos.
- Incentiva designs desacoplados e testáveis.
- A suíte atua como documentação viva e executável.
- Ritmo inicial mais lento e uma curva de aprendizado real.
- Pode enfatizar demais unidades isoladas e deixar passar lacunas de integração.
- Testes também são código — precisam ser mantidos e refatorados.
- Não substitui testes exploratórios, de integração ou de ponta a ponta.
