O ciclo curto: teste que falha, diff mínimo, leitura
Por que três iterações de dez linhas superam uma de trezentas — e como pedir para receber diff em vez de arquivo inteiro.
A tentação é pedir a feature inteira de uma vez. Chega um arquivo de 300 linhas que parece pronto, você lê as primeiras 40, cansa, e aceita o resto no confiar.
- Dimensionar o pedido para caber numa revisão de verdade.
- Exigir o teste antes da implementação.
- Ler o diff em vez do arquivo.
O limite não é a capacidade do modelo — é a sua. Revisão humana de código tem um teto real: acima de algumas dezenas de linhas por vez, a taxa de defeito encontrado cai rápido. Código que você não revisou de verdade não é código revisado, e a origem dele (você, um colega ou um assistente) não muda isso.
O ciclo curto inverte a ordem do risco: em vez de descobrir no final que a premissa da linha 12 estava errada, você descobre na linha 12.
| Uma rodada grande | Três rodadas curtas | |
|---|---|---|
| Linhas por revisão | ~300 | ~30 |
| Quando o erro de premissa aparece | No fim, com tudo construído em cima | Na primeira rodada |
| Custo de descartar | A feature inteira | Dez minutos |
| Chance de você ler mesmo | Baixa | Alta |
| Sensação | Rápido | Lento |
A última linha é a razão de quase todo mundo escolher a coluna errada.
A ordem que funciona
- Escolha um comportamento observável — não uma feature.
- Peça o teste que falha por causa da ausência desse comportamento.
- Rode o teste e confirme que ele falha pelo motivo certo.
- Peça o menor diff que faz o teste passar.
- Rode a suíte inteira, não só o teste novo.
- Leia o diff linha a linha antes de aceitar.
- Repita para o próximo comportamento.
Um teste pode falhar por erro de importação, nome errado ou banco de teste não migrado — e você acha que está vendo a ausência do comportamento. Aí implementa, o teste passa, e você acredita ter provado algo que não provou.
Leia a mensagem de falha. Ela precisa dizer o que você espera que diga.
Contexto: [cole o CONTEXT.md] Comportamento a implementar (só este): [Dado/Quando/Então de um único critério] Código relevante: [cole apenas o arquivo ou a função que muda] Etapa 1 — Não implemente ainda. Escreva o teste que falha hoje por causa deste comportamento faltando. Diga qual mensagem de falha eu devo ver. Depois que eu confirmar a falha, etapa 2 — o menor diff que faz passar, no formato de diff, com uma frase explicando cada trecho alterado. Não altere [itens]. Não adicione dependência.
"Diga qual mensagem de falha eu devo ver" é a linha que transforma o passo 3 em algo verificável.
Aqui está o CartService.ts completo com a alteração aplicada: [280 linhas]
Você não consegue ver o que mudou. Na prática, aceita tudo ou reescreve tudo.
@@ cart.service.ts:44
- const total = itens.reduce((s, i) => s + i.preco, 0);
+ const total = itens.reduce((s, i) => s + i.preco * i.qtd, 0);
@@ cart.service.ts:48
- return { total: carrinho.total };
+ return { total: carrinho?.total ?? 0 };
Mudança 1: o total ignorava a quantidade.
Mudança 2: carrinho ausente devolvia undefined.total.Duas linhas para revisar, cada uma com um motivo. Dá para discordar da segunda sem descartar a primeira.
A diferença: Pedir o formato diff não é preferência estética: é o que mantém a revisão dentro do que uma pessoa consegue conferir de verdade.
- O pedido cobre um comportamento só.
- O teste foi escrito e falhou antes do código existir.
- A mensagem de falha era a esperada.
- A resposta veio em diff, não em arquivo inteiro.
- A suíte inteira rodou depois da mudança.
- Rodadas curtas parecem mais lentas e chegam antes, porque o erro de premissa aparece enquanto ainda custa dez minutos.
Comentários e dúvidas
Inscreva-se grátis para comentar, tirar dúvidas, marcar seu progresso e emitir o certificado ao fim do curso.
Inscrever-se grátis com GoogleAinda não há comentários nesta aula.