Controle UI E2E
Fluxo de Trabalho
- Selecionar prova. Use a lane E2E de navegador existente para roteamento, inicialização, handshake do Gateway e fluxos completos do usuário; use testes de navegador/unidade para lógica de renderização isolada. Leia cada ramificação abaixo que corresponda ao resultado solicitado. Concluído: cada comportamento alterado tem um cenário nomeado e um limite de prova.
- Preparar fixtures. Reutilize
ui/src/test-helpers/control-ui-e2e.tscom dados sintéticos do Gateway. Estenda suas opções de cenário tipadas para respostas ausentes. Use a instalação de dependências existente; preserve as instalações usadas por outros jobs. Credenciais reais de Gateway/provedor exigem autorização explícita de prova ao vivo. Siga a política de testes para o posicionamento da execução. Concluído: o fluxo alvo é executado contra a fonte pretendida ou o build de produção e cada resposta de fixture necessária está definida. - Exercitar o comportamento. Instale o mock antes da navegação. Atue através de controles visíveis e afirme tanto o resultado renderizado quanto as requisições relevantes ao Gateway. Resolva comportamentos inesperados com o proprietário do produto ou da fixture antes de repetir. Concluído: cada cenário atinge seu resultado afirmado, ou tem uma falha retida identificando a afirmação não atendida.
- Entregar evidências. Aplique as regras de artefatos abaixo e as verificações da ramificação selecionada. Relate resultados verificados, falhas e estados não testados separadamente. Concluído: cada resultado reivindicado tem evidências inspecionáveis; lacunas restantes são nomeadas.
Teste de Estresse de UI
Para mudanças substanciais de layout/componente ou feedback de design multi-estado, leia prova visual antes de construir a galeria de teste de estresse. Pequenas alterações de cópia/ícone podem usar prova focada.
Padrão de Prova Visual
Para mudanças de aparência, capturas de tela, captura de estado transitório ou vídeo, leia prova visual. Mudanças de aparência exigem evidências de antes/depois inspecionadas; apenas afirmações de comportamento podem ser suficientes para correções não visuais.
Auditorias de Desempenho de Interação
Para lentidão de UI, auditorias de capacidade de resposta ou coleta automática de rastreamento do Chrome, leia perfil de interação antes de escolher o build, fixtures e limites de medição.
Evidências do Run Inspector
Para evidências de execução/decisão, leia captura do Run Inspector antes de selecionar um recibo.
Artefatos
- Aloque com
createControlUiE2eArtifactDir(scope, parentDir?), uma vez por tentativa ou invocação independente. Passe o diretório para auxiliares de captura; mantenha nomes de arquivo de estágio distintos e o relatório, capturas de tela, rastreamentos e vídeo juntos. - O auxiliar é dono da seleção do diretório pai. Preserve os controles de saída existentes, portões, viewport e opções de gravação; use seu caminho retornado no relatório final.
- Retenha tentativas falhas e bem-sucedidas. Limpe apenas diretórios exatos de propriedade após revisão; nunca limpe diretórios pai compartilhados ou substitua provas anteriores.
- Diagnósticos de tempo limite usam filhos novos de seu diretório de diagnóstico pai existente. Mantis retém cada tentativa. Suítes Real-Gateway,
chat-outbox-*echat-attachment-read-lifecycletêm proprietários separados: verifique seu comportamento de retenção antes de reivindicar captura segura para repetição.
Executando um teste focado
Use os scripts atuais em package.json e a política de testes. Para um teste de navegador focado em uma worktree:
node scripts/run-vitest.mjs run --config test/vitest/vitest.ui-e2e.config.ts --configLoader runner ui/src/e2e/chat-flow.messaging.e2e.test.ts