"Eu também virei testador do meu app (em 2014, sem IA): o que me tirou disso"
"Em 2014 eu clicava em 30 telas toda sexta. Escrever teste não bastou: o que me tirou foi parar de ser eu quem lembra de rodar. Como fazer isso hoje."
"I feel all I was doing was being a tester for the Replit app."
"Sinto que tudo que eu fazia era ser testador do app do Replit." É de um usuário falando do próprio projeto, e já usei a frase num post sobre quanto isso custa. Volto nela porque devo uma confissão: eu também. Em 2014, sem IA nenhuma, com código escrito por mim.
A sexta-feira das trinta telas
Eu tinha uns três anos de carreira e cuidava sozinho de um sistema de pedidos pra um cliente. Toda alteração, por menor que fosse, terminava igual: eu abria o sistema e clicava. Login, cadastro de cliente, pedido novo, desconto, frete, relatório, impressão. Umas trinta telas, na sexta à tarde, antes de publicar.
Eu sabia programar, e isso não me salvou de nada. Escrever o código e conferir o código eram dois trabalhos, e o segundo era todo meu, toda semana, inteiro.
Até a semana em que mexi no desconto e o frete parou de somar certo em pedido com dois endereços de entrega. Eu tinha clicado nas trinta telas. Só nunca fazia pedido com dois endereços; quem fazia era o cliente. Fiquei sabendo por ele, na segunda.
O que me tirou disso não foi o teste
Foi o que veio depois, e eu levei um tempo pra perceber a diferença.
Primeiro escrevi testes: pequenos programas que conferem uma regra sozinhos, tipo "pedido com dois endereços soma os dois fretes". Funcionou por umas semanas. Eu rodava antes de publicar. Aí veio uma sexta corrida, esqueci de rodar e publiquei um erro que um teste meu teria pegado.
O teste existia. Eu era o botão que fazia ele rodar, e o botão falhou.
A virada foi tirar esse botão de mim. Configurei uma máquina pra rodar todos os testes sozinha, toda vez que eu mandava código novo, e me mostrar o resultado antes da publicação. Isso tem nome: integração contínua, em inglês continuous integration, ou CI. Em 2014 me custou um servidor separado e uns dias de configuração.
Continuei clicando, mas em menos coisa, e a sexta voltou a ter hora pra acabar. O que mudou de verdade foi outra coisa: eu deixei de ser o único jeito de saber se o sistema funcionava.
Você está onde eu estava, e não é por falta de capacidade
É que ninguém montou pra você a parte que roda sem você.
A documentação do Claude Code, a ferramenta de programar da Anthropic, descreve a minha sexta-feira melhor do que eu. Sem uma conferência que a IA consiga rodar, diz o texto, "parecer pronto" é o único sinal disponível, e "você vira o ciclo de verificação: todo erro espera você perceber". Está no manual de quem vende a IA. Não é fraqueza sua; é o desenho padrão.
A diferença entre 2014 e hoje é que a parte que me custou um servidor agora é de graça.
Faz hoje: tire o botão de você
Vale se o código do seu app está no GitHub, o site onde o código fica guardado com histórico. No Lovable, a sincronização com o GitHub manda cada mudança pro seu repositório (a pasta do projeto lá dentro), segundo a documentação. E vale se você já tem pelo menos um teste; se não tem, comece pelo primeiro teste automático e volte aqui.
1. Peça a rodada automática, num pedido só, sem nenhuma outra mudança junto:
Crie um workflow do GitHub Actions que rode todos os testes do projeto
a cada push no branch principal.
- Use o mesmo comando que você usa pra rodar os testes aqui.
- Não altere nenhum outro arquivo.
- Me diga o nome do arquivo criado e onde, no site do GitHub,
eu vejo o resultado de cada rodada.
Traduzindo: GitHub Actions é o serviço do próprio GitHub que roda tarefas automáticas. Push é o envio de código novo pro GitHub. Branch principal é a versão oficial do código. A documentação do GitHub diz que dá pra configurar a rodada pra acontecer "quando código novo é enviado pro repositório".
2. Veja a primeira rodada. No repositório, aba Actions. Cada rodada aparece com um ícone: verde passou, vermelho falhou. Na lista de commits (cada ponto salvo do código), o mesmo ícone aparece do lado de cada um.
3. Prove que ela pega erro. Peça uma mudança que quebre de propósito uma regra que tem teste: "mude o cupom de 10% pra 20% sem alterar o teste". Espere o vermelho. Depois peça pra desfazer e veja o verde voltar. Rodada que você nunca viu ficar vermelha pode não estar conferindo nada.
4. Antes de publicar, um olhar só: o ícone do último commit está verde? Vermelho, não publica; abre a rodada, copia as linhas da falha e leva pra IA.
Custo: em repositório público é grátis; em repositório particular, a conta gratuita do GitHub inclui 2.000 minutos de rodada por mês, segundo a página de cobrança. Confira o seu consumo depois da primeira semana em Settings → Billing.
Era uma parede de várias
A rodada automática protege as regras que já têm teste. Ela não escolhe quais coisas merecem teste e quais não, não sabe o que é dado de cliente, e não adianta nada se o código não estiver numa conta sua.
Eu juntei essas peças ao longo de anos, uma por crise, sempre fora de ordem. Elas têm ordem: código seu, depois regras provadas, depois a conferência que roda sem você lembrar. Ninguém precisa levar anos de novo pra descobrir isso.
Fontes
- Claude Code Docs, "Best practices for Claude Code" (seção "Give Claude a way to verify its work": sem uma conferência executável, "looks done" é o único sinal e "you become the verification loop"): https://code.claude.com/docs/en/best-practices
- GitHub Docs, "Continuous integration" (rodar a conferência quando código novo é enviado ao repositório): https://docs.github.com/en/actions/get-started/continuous-integration
- GitHub Docs, "GitHub Actions billing" (grátis em repositório público; 2.000 minutos/mês no GitHub Free para repositório particular): https://docs.github.com/en/billing/concepts/product-billing/github-actions
- Lovable Docs, "Git sync overview" (mudanças no Lovable vão pro repositório; commits no branch sincronizado voltam pro projeto): https://docs.lovable.dev/integrations/git-sync-overview