Corrija testes E2E que falham observando o navegador real

## Defina antes do teste como o sucesso aparece no navegador Antes de executar um teste de ponta a ponta, transforme o comportamento solicitado em condições que possam ser observadas no navegador real. Registre a URL ou rota inicial, o estado necessário da conta ou dos dados de teste, a área visível quando relevante, as ações do usuário e o resultado visível exato que caracteriza o sucesso. Inclua o estado de acessibilidade, a navegação, o estado persistente e o conteúdo fornecido pela rede quando fizerem parte do comportamento. - Prefira funções visíveis ao usuário, rótulos e identificadores de teste dedicados e estáveis em vez de classes de estilo ou posições no DOM. - Diferencie a interface do executor de testes da aplicação em teste; as provas de uma não descrevem automaticamente a outra. - Defina tanto provas positivas, como uma confirmação visível ou um valor alterado, quanto provas negativas, como a ausência de um aviso de erro. - Expresse as expectativas de tempo por meio de uma condição observável de prontidão, e não de uma espera arbitrária. Não enfraqueça uma asserção apenas para fazer o teste passar. Se o comportamento esperado for ambíguo, pare e esclareça o contrato de aceitação antes de alterar o código de teste ou do produto. ## Rode o teste num navegador real e guarde capturas de tela e logs Inicie o cenário E2E relevante de menor alcance em um navegador real compatível, usando o caminho normal da aplicação. Mantenha explícitos a configuração, os dados de teste, o estado de autenticação, a área visível e os recursos ativados, com detalhes suficientes para repetir a execução. Se houver um modo com interface visível ou de depuração, use-o quando o estado visual ou a interação com o navegador for importante. Em caso de falha, reúna provas antes de editar qualquer coisa: - o cenário que falhou e a asserção ou o comando exato; - uma captura de tela ou instantâneo do navegador no momento da falha; - o DOM da aplicação ao redor do elemento-alvo, incluindo o nome acessível e o estado; - erros relevantes do console do navegador e solicitações de rede que falharam ou foram inesperadas; - a URL atual, redirecionamentos, indicadores de carregamento e mensagens de erro visíveis na aplicação; - registros de horário ou identificadores de execução necessários para correlacionar os registros do servidor, quando disponíveis. Faça uma inspeção direcionada em vez de despejar estados sem relação. Reproduza uma vez nas mesmas condições quando for necessário distinguir uma falha estável de uma falha transitória, mas não inicie um ciclo de novas tentativas sem limite. ## Classifique a causa da falha: teste, código ou ambiente Classifique a falha observada como causa de teste, causa de implementação ou causa de ambiente. A classificação deve ser sustentada por provas do navegador e, quando necessário, pela menor inspeção relevante do código-fonte ou dos registros. - Causa de teste: o produto se comporta conforme o contrato de aceitação, mas o teste usa um seletor desatualizado, uma asserção incorreta, dados de teste inválidos, uma sequência errada ou uma condição de prontidão inadequada. - Causa de implementação: o comportamento visível ao usuário viola o contrato de aceitação, por exemplo, um controle não responde, o estado ou a navegação estão incorretos, há uma regressão de acessibilidade ou uma solicitação da aplicação falha por causa do código do produto. - Causa de ambiente: o teste e a implementação podem estar corretos, mas um pré-requisito está ausente ou não está saudável, como um serviço indisponível, credenciais inválidas, um navegador incompatível, dados iniciais ausentes, uma configuração incorreta ou recursos esgotados. Quando as provas forem contraditórias, escreva hipóteses concorrentes e execute uma verificação discriminante de cada vez. Não classifique todo tempo limite como problema de teste e não altere o código do produto apenas porque um teste falhou. Mantenha a classificação como provisória até que as provas descartem as alternativas mais próximas. ## Faça a menor correção sem enfraquecer as asserções Escolha a correção que trate a causa classificada sem uma refatoração ampla. Preserve o contrato de aceitação e o comportamento existente do usuário fora do caminho que falha. - Para uma causa de teste, atualize apenas o seletor, a asserção, os dados de teste, a sequência de ações ou a condição de prontidão que contradiga o estado observado do navegador. - Para uma causa de implementação, adicione ou mantenha um teste de regressão que falhe quando for viável; em seguida, altere somente a menor parte da lógica do produto necessária para restaurar o comportamento especificado. - Para uma causa de ambiente, corrija ou documente o pré-requisito ausente; não o oculte com esperas maiores, asserções desativadas ou novas tentativas incondicionais. - Prefira sinais determinísticos, como prontidão visível, solicitações concluídas ou estado estável, em vez de esperas de duração fixa. - Mantenha as alterações de testabilidade neutras para o usuário: adicione identificadores estáveis ou rótulos acessíveis sem vincular os testes a um leiaute circunstancial. Antes de editar recursos protegidos, gerados, de produção, destrutivos ou que contenham credenciais, pare e obtenha a autorização necessária. Nunca exponha segredos em testes, registros, capturas de tela, dados de teste ou relatórios. ## Repita o mesmo cenário e pare se as falhas se repetirem Após a correção, execute novamente o cenário exato que falhou com as mesmas condições do navegador e o mesmo contrato de aceitação. Uma aprovação só conta quando o navegador alcança visivelmente o estado de sucesso definido e o executor não relata nenhuma falha oculta. Confirme que as provas do console e da rede já não mostram o erro causal quando esses sinais fizeram parte do diagnóstico. Em seguida, execute o menor escopo de regressão diretamente afetado: o cenário próximo, o arquivo de funcionalidade ou o grupo de testes estreitamente relacionado. Não amplie para um conjunto completo sem relação, exceto quando a alteração tiver impacto amplo ou o usuário solicitar isso explicitamente. Se a nova execução falhar de outra forma, retorne à coleta e à classificação das provas em vez de acumular alterações especulativas. Limite as tentativas repetidas. Depois de duas correções ineficazes com a mesma abordagem, reavalie o diagnóstico e escolha outra verificação discriminante. Depois de três falhas consecutivas sem novas provas, pare e informe o bloqueio em vez de continuar alterando o código-base. ## Informe primeiro se passou, falhou ou ficou bloqueado, com evidências Pare com sucesso somente quando o contrato de aceitação original observável no navegador for aprovado, o escopo de regressão diretamente afetado for aprovado e nenhum erro causal relevante permanecer. Pare também quando o avanço exigir uma autorização ausente, credenciais, infraestrutura indisponível, uma ação destrutiva ou uma decisão de produto que não possa ser inferida com segurança. Relate o resultado com provas suficientes para que outra pessoa possa verificá-lo: - o cenário e as condições de navegador usados; - a falha observada e sua classificação; - as provas que sustentaram a classificação; - a alteração mínima realizada ou o pré-requisito não resolvido; - as novas execuções exatas realizadas e seus resultados; - o risco restante, as verificações mais amplas omitidas e a próxima ação necessária. Comece indicando aprovado, falhou ou bloqueado. Não declare a conclusão com base apenas na inspeção do código, em um teste unitário aprovado ou em um DOM simulado quando a condição de sucesso depender de um navegador real.