"Verde, vermelho e \"acho que sim\": os três estados de uma regra do seu app"

"Says that it has fixed it but it doesn't."

"Diz que consertou, mas não consertou." É de um usuário na comunidade do Lovable, registrada na pesquisa deste blog. Relato, não estatística. Mas repara no que vem depois dessa frase: a pessoa só descobriu que não estava consertado porque, por acaso, clicou ali de novo.

Agora a pergunta que eu quero que você responda com honestidade, sobre a regra mais importante do seu app (o cálculo do total, o desconto, o prazo de entrega, quem pode ver o quê):

Como você sabe, hoje, que ela está certa?

Se a resposta foi "testei semana passada e tava", ou "a IA disse que tá", ou só "acho que sim", você acabou de descobrir em qual dos três estados ela está.

O mapa: três estados, e só dois são informação

Toda regra do seu app está em um destes:

Verde. Existe um teste pra ela, ele rodou e passou. Teste, aqui, é um pequeno programa que confere se outro faz o que devia: "pedido de 3 marmitas de R$ 20 com cupom de 10% tem que dar R$ 54". Ele roda em segundos, sem ninguém clicar em nada, e responde sim ou não.

Vermelho. Existe um teste, ele rodou e falhou. Parece o pior estado. É o segundo melhor: você sabe exatamente qual regra quebrou, e descobriu antes do cliente.

"Acho que sim". Não existe teste. A regra está certa até alguém perceber que não está, e esse alguém costuma ser o cliente que pagou R$ 60 num pedido de R$ 54.

Verde e vermelho são informação. "Acho que sim" é esperança com cara de verde, porque o app abre, a tela está bonita e nada piscou.

E tem um quarto caso escondido no primeiro: o verde que nunca foi vermelho. Teste que nunca falhou pode estar conferindo outra coisa, ou não conferindo nada. Já escrevi sobre por que nem "o teste passou" é prova; o jeito de resolver está mais abaixo, e é simples.

Por que quase toda regra do seu app mora no "acho que sim"

Não é desleixo seu. É o padrão de fábrica.

A documentação de testes do Lovable diz isso numa linha: "a maioria das ferramentas de verificação só roda quando você pede". O Lovable sabe escrever teste de tela e teste da parte do servidor, e eles ficam guardados no projeto pra rodar de novo. Mas só existem se alguém pediu. Você pediu o app. Ninguém te contou que tinha que pedir a prova junto.

Então o app gerado nasce com dezenas de regras e zero teste. Cada vez que você pede uma mudança, todas elas voltam pro "acho que sim", inclusive a que você conferiu na mão ontem. É por isso que você virou o testador do próprio app: no lugar do teste, tem você.

O placar: 20 minutos, hoje

1. Escreva as regras em português, com número. Cinco linhas, as cinco que mais doem se estiverem erradas. Não "o desconto funciona", e sim o exemplo concreto:

REGRA                                         ESTADO
3 marmitas de R$ 20 + cupom 10% = R$ 54       acho que sim
Cupom vencido não dá desconto                 acho que sim
Pedido depois das 15h entrega amanhã          acho que sim
Quantidade zero ou negativa é recusada        acho que sim
Cliente só vê os próprios pedidos             acho que sim

Se você não consegue escrever o exemplo com número, essa é a primeira descoberta: a regra não está definida nem na sua cabeça. Antes de testar, decida. É a letra D do ciclo, Definir.

As seis entradas maldosas são ótimas fontes de linha pra esse placar: cada "deveria recusar" de lá vira uma regra aqui.

2. Escolha a regra que mais custa se estiver errada. Quase sempre é a que mexe com dinheiro.

3. Peça o teste, e peça pra ver ele falhar. Cole isto, trocando a regra pela sua:

Escreva um teste automático para esta regra:
"3 marmitas de R$ 20 com cupom de 10% dão R$ 54.
Cupom vencido não dá desconto."

1. Rode o teste e cole a saída inteira aqui.
2. Agora quebre a regra DE PROPÓSITO (troque 10% por 20%),
   rode o mesmo teste e cole a saída. Ele tem que falhar.
3. Desfaça a quebra, rode de novo e cole a saída.
Não altere o teste para fazer passar.

O passo 2 é o que ninguém faz e o que mais vale. Se você estragou a regra e o teste continuou verde, ele não estava conferindo nada. Não é invenção minha: a documentação do Claude Code, ferramenta de programar da Anthropic, recomenda pedir à IA que "escreva um teste que falha reproduzindo o problema, e depois conserte". Um teste só vale depois que você o viu ficar vermelho.

No Lovable, esse pedido funciona como está. No Claude Code também. No Replit, peça o mesmo ao Agent. No chat comum do navegador não dá, porque ele não roda o seu app: ali a regra continua em "acho que sim", e é melhor saber disso.

4. Atualize o placar. Viu verde, viu vermelho com a regra quebrada, viu verde de novo? Essa linha virou verde. Uma de cinco. Daqui pra frente, depois de toda mudança, peça: "rode todos os testes e cole a saída". Essa regra nunca mais volta pro "acho que sim" sozinha.

Era uma pergunta de dez

"Você prova que a regra funciona sem clicar em tudo de novo?" é uma das dez perguntas do checklist "Protótipo ou produto?". As vizinhas dela: quem é dono do código, quem é dono do banco, se você volta pra ontem quando quebra, se o login protege ou só aparece, se outra pessoa usa sem você do lado, se você sabe quanto custa por mês.

O placar de hoje resolve uma linha de uma pergunta. Transformar as cinco linhas em verde, decidir quais regras merecem teste e quais não, e fazer isso na fase certa, depois que o código e o banco são seus e antes de gente de fora usar, é a ordem. Mas a primeira linha você pinta de verde hoje, e a partir daí já sabe a diferença entre "funciona" e "acho que funciona".

Fontes

• Lovable Docs, "Testing" (teste de tela, teste de função do servidor e teste no navegador; testes ficam guardados como arquivo; "Most verification tools run only when you ask for them"): https://docs.lovable.dev/features/testing
• Claude Code Docs, "Best practices for Claude Code" ("write a failing test that reproduces the issue, then fix it"; "If you can't verify it, don't ship it"): https://code.claude.com/docs/en/best-practices