O ponto de partida honesto
Se você não sabe ler o código, você não tem como revisar o código — e pode parar de se sentir mal por isso. A alternativa não é revisar: é verificar o comportamento. É o que os seus usuários vão fazer de qualquer jeito, e isso pega um tipo de problema que a leitura deixaria passar.
Onde costumam estar os bugs no código do Lovable
Apps gerados falham em uma ordem previsível. Verifique estes pontos primeiro.
| Parece salvo, mas não está | Um formulário mostra a mensagem de sucesso e o registro some depois de um refresh. Sempre recarregue a página antes de acreditar em um salvamento. |
| Estados vazios e de erro | O caminho feliz foi construído e demonstrado. Os casos de zero resultados e de requisição com falha, muitas vezes, não. Teste sem nenhum dado e com uma entrada errada de propósito. |
| O segundo usuário | Tudo funciona para a conta que construiu o app. Permissões, propriedade dos dados e visibilidade são as primeiras coisas a quebrar para qualquer outra pessoa. Entre com uma segunda conta antes de mostrar o app para alguém. |
A verificação que continua funcionando
Verificar na mão dá conta de um projeto de fim de semana e deixa de escalar no momento em que você continua escrevendo prompts. Cada nova instrução pode desfazer em silêncio algo que funcionava ontem, e a passada manual fica mais curta a cada vez que você a repete.
O que você quer é que as verificações fiquem registradas e rodem automaticamente, descritas em linguagem simples em vez de em código de teste. A configuração coloca essa capacidade nas mãos do agente, para que a verificação aconteça junto com a construção.
Tudo isso também está disponível no dashboard do TestSprite, que costuma ser o melhor caminho se o terminal não é onde você trabalha. Os detalhes da CLI estão no repositório da CLI.
Três verificações que valem a pena desde o primeiro dia
Faça o cadastro e depois entre de novo. É aqui que mais apps gerados quebram, e é a primeira coisa que um usuário real faz.
Crie alguma coisa, recarregue e confirme que ela continua lá. Essa única verificação pega a falha mais comum e mais constrangedora.
Faça aquilo para que o seu app existe, usando uma conta recém-criada. Se isso funciona para um desconhecido, você tem alguma coisa nas mãos.
Como descrever um bug para que a correção acerte o alvo
Quando algo está errado, o instinto é dizer "isso está quebrado". Isso dá muito pouco ao agente, e o que volta é uma mudança que conserta algo ao lado do problema.
Três frases funcionam muito melhor, e você não precisa de vocabulário técnico para nenhuma delas. O que você fez, na ordem. O que você esperava. O que aconteceu no lugar disso. "Preenchi o formulário e apertei salvar, esperava ver o novo item na lista, a lista ficou vazia até eu recarregar" é um relato de bug genuinamente bom, e aponta direto para o defeito.
Essas mesmas três frases também são a verificação que você guarda. Escritas uma vez, elas podem ser reexecutadas depois de cada mudança futura, e é assim que você impede o mesmo problema de voltar.
A ordem em que verificar as coisas
Existe uma sequência que encontra problemas mais rápido do que sair clicando por aí, e ela leva cerca de dez minutos.
Comece deslogado e faça o cadastro como um usuário totalmente novo, porque esse é o caminho que você menos percorreu pessoalmente. Depois faça a única coisa para a qual o seu app existe, até o fim, e recarregue a página antes de acreditar em qualquer coisa. Depois faça de novo, só que errado: deixe um campo obrigatório em branco, coloque texto onde vai um número, envie algo absurdo. Depois exclua alguma coisa e confirme que ela realmente sumiu, em vez de apenas ter ficado escondida.
Cada um desses quatro passos leva um ou dois minutos e cada um corresponde a um grupo de falhas típicas de apps gerados. Fazer nessa ordem importa, porque um cadastro quebrado torna impossível testar tudo o que vem depois, e é comum alguém passar uma hora em uma funcionalidade que ninguém consegue alcançar.
Na hora de compartilhar o app
Antes de um app ir para qualquer lugar de verdade, faça as verificações rodarem automaticamente a cada mudança, em vez de quando você lembrar. Duas formas de fazer isso:
Conecte o repositório pelo dashboard e as execuções partem do deploy que você já gera, ou então adicione um passo ao seu próprio fluxo de trabalho.
Como o TestSprite faz a verificação por você
Você descreve em linguagem simples o que deveria ser verdade e o TestSprite faz os cliques. Sem código de teste, sem framework, sem precisar de terminal: crie um projeto no dashboard, aponte para o seu app e diga como é uma versão funcionando.
Os quatro grupos desta página são exatamente o que ele cobre. Ele se cadastra com uma conta nova, cria alguma coisa e recarrega para confirmar que ficou salva, envia algo inválido para checar se o app avisa, e roda o mesmo fluxo como um segundo usuário para pegar as suposições de permissão embutidas na sua própria sessão.
A parte que importa enquanto você continua escrevendo prompts é que as verificações permanecem. Cada mudança é verificada contra tudo o que funcionava antes dela, e é isso que interrompe o ciclo em que consertar uma coisa quebra outra em silêncio.
Preciso saber programar para isso?
Não. As verificações são descritas em linguagem simples e rodam sobre o app pela interface dele, do mesmo jeito que uma pessoa usaria.
Por que o meu app funciona para mim e não para os outros?
Normalmente é permissão ou propriedade dos dados. A conta que construiu o app tem registros e acessos que uma conta nova não tem. Testar como um segundo usuário revela isso na hora.
Devo testar antes ou depois de escrever mais prompts?
Os dois, e o segundo importa mais. É uma verificação que já existia antes da sua última instrução que mostra se aquela instrução quebrou alguma coisa.
E se a correção fica quebrando outra coisa?
Esse é o sinal de que as verificações precisam rodar continuamente, e não só no final. Cada mudança é verificada contra tudo o que funcionava antes dela.
Isso vale só para o Lovable?
Não. As mesmas falhas aparecem em qualquer coisa gerada rápido, seja lá o que a produziu. Quem usa o Lovable esbarra nelas mais cedo porque coloca no ar mais rápido.
Você não tem como revisar o código. Você tem como verificar o comportamento.
A maioria dos bugs no código do Lovable são salvamentos que não persistem, estados vazios que ficaram faltando e coisas que só funcionam para a conta que as criou. Verifique esses três primeiro e depois deixe as verificações automáticas antes de compartilhar o app.