Boas práticas

Mantenha os testes pequenos

Um teste verifica uma coisa. Coloque cada verificação em sua própria etapa para que uma falha esteja diretamente relacionada à verificação. Um teste com dez etapas é mais fácil de ler e corrigir do que um teste com cinquenta.

Use seletores estáveis

Use el("<element id>"). Não selecione por texto, posição ou pelas próprias classes do Bubble. O texto muda quando o conteúdo é editado. As classes mudam em tempo de execução. Os IDs dos elementos não mudam, e o Buildprint os mapeia em tempo de execução.

Delimite o escopo dos elementos dentro de elementos reutilizáveis e grupos repetidos (você precisa decidir qual célula selecionar). Sem delimitação de escopo, buildprint check avisará você, porque o elemento reutilizável ou o elemento pode aparecer mais de uma vez.

Uma pasta por funcionalidade

Coloque os testes de uma funcionalidade em uma única pasta: tests/agency/, tests/billing/. Execute a pasta enquanto trabalha nessa funcionalidade. Execute --all antes de uma versão.

Seja responsável pelos seus dados

Cada execução cria os dados necessários em setup e os remove em teardown. Dê aos registros de teste nomes com $BUILDPRINT_TEST_RUN_ID para que as execuções não entrem em conflito e a limpeza seja precisa. Defina onFailure: "continue" nas etapas de teardown para que uma limpeza com falha não oculte as demais.

Não dependa de dados criados por outro teste. Não dependa de dados inseridos por uma pessoa.

Use etapas de agente somente quando necessário

Uma etapa de agente pausa a execução, faz uma captura de tela e exige uma decisão de um agente. Use-a para verificações que um comando não pode fazer (por exemplo, verificar se um gráfico está correto, se um layout não está quebrado ou se a qualidade da resposta do chat de IA é boa). Escreva o resumo de modo que um agente sem contexto possa decidir: uma frase sobre a tarefa, onde procurar e quais são os critérios de aprovação e reprovação

Execute antes de publicar

Execute a pasta alterada após cada buildprint apply. Execute --all no branch antes de implantá-lo. O Dashboard mostra o branch visado por cada execução.

Corrija ou exclua testes instáveis

Verifique as regressões do Dashboard todos os dias. Um teste que falha sem nenhuma alteração no aplicativo é 'instável', o que significa que ele falha de forma imprevisível. Corrija-o ou exclua-o, pois, se você tiver testes que simplesmente falham aleatoriamente, começará a ignorar todo o conjunto de testes, o que elimina sua utilidade.

Causas comuns de etapas instáveis:

• Um elemento oculto foi clicado antes de aparecer. Adicione agent-browser wait <selector> primeiro.

• Uma espera mais longa que o padrão. Passe --timeout <ms> para agent-browser wait e defina timeoutMs alguns segundos acima desse valor.

• Dados de teste deixados por uma execução com falha. Faça com que setup os limpe, não apenas teardown.

• Um nome gerado longo demais para uma entrada do Bubble. Mantenha-o curto: Test $(echo "$BUILDPRINT_TEST_RUN_ID" | cut -c1-12).