Escrever código em ciclos curtos

Laboratório: uma regra, um teste, um diff

Mão na massa 5 min de leitura 35 min de prática Você leva: Ciclo completo registrado (teste + diff + prova de regressão)

Executar o ciclo completo numa regra real do seu sistema e provar que o teste detecta a regressão.

Este laboratório tem um passo que quase ninguém faz e que é o mais importante: quebrar o código de propósito no final, para ver se o teste percebe.

Mão na massa35 min

Implementar uma regra pequena e real com o ciclo curto, e provar que o teste criado tem poder de detecção.

Escolha uma regra de negócio que caiba em uma função: um cálculo, uma validação, uma condição de permissão. Se a regra exigir mais de um arquivo, ela é grande demais para este exercício.

Escreva a regra em Dado/Quando/Então, com um número concreto.
Peça o teste que falha hoje, exigindo que a resposta diga qual mensagem de falha você deve ver.
Rode. Confirme que a mensagem é a prevista — se for outra, o teste está errado, não o código.
Peça o menor diff que faz o teste passar, em formato de diff.
Leia o diff linha a linha e rode a suíte inteira.
Agora quebre de propósito: inverta uma comparação, troque um sinal, mude um limite.
Rode de novo. O teste precisa ficar vermelho. Se ficar verde, ele não testa o que você pensa que testa.
Desfaça a quebra e registre o ciclo no seu documento.

Deu certo quando

A mensagem de falha inicial era a prevista.
O diff tem menos de 20 linhas.
A suíte inteira passa.
O teste ficou vermelho quando você sabotou o código.

Se travar: Se o teste continuou verde depois da sabotagem, quase sempre é uma destas três causas: a asserção só verifica que algo "não é nulo"; o teste exercita um caminho que não passa pela regra; ou há um mock cobrindo justamente a parte alterada. A próxima aula é sobre isso.

Você leva daquiCiclo completo registrado

Um registro curto por ciclo. Depois de alguns, ele vira o seu histórico de como você usa IA — útil em revisão, em retrospectiva e para responder "como isso foi feito?".

## Ciclo: [nome da regra]
Data: [data]

**Regra**
Dado [contexto], quando [ação], então [resultado observável com número].

**Teste antes**
- Mensagem de falha esperada: [texto]
- Mensagem de falha obtida: [texto]
- Bateu? [sim/não — se não, o que ajustei]

**Diff aplicado**
- Linhas alteradas: [n]
- Arquivos: [lista]
- O que eu recusei da sugestão e por quê: [texto]

**Prova de detecção**
- Sabotagem aplicada: [ex: troquei >= por >]
- Teste ficou vermelho? [sim/não]

**Tempo**
- Estimado: [x] · Real: [y]

Onde guardar: Um arquivo por feature em docs/ciclos/, ou colado na descrição do pull request.

Por que registrar o que você recusou

A linha "o que eu recusei e por quê" é a que mais rende com o tempo. Ela mostra onde o assistente erra no seu contexto específico — e esse padrão vira material para melhorar o seu CONTEXT.md.

Também é a resposta pronta para a pergunta que vai aparecer em algum momento: "você revisou ou só aceitou?".

Em uma frase

Um teste que nunca ficou vermelho não provou nada; sabotar o código de propósito é a única forma barata de descobrir isso.

← Aula anterior Próxima aula →

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 Google

Ainda não há comentários nesta aula.