Skip to content

feat: adiciona o playwright para testes E2E e acessibilidade

Natanael de Sousa Leite requested to merge feat/playwright-testing into next

Descrição

Este Merge Request introduz o Playwright como uma nova ferramenta para aprimorar nossos testes de ponta a ponta (E2E) e de acessibilidade. O Playwright é uma biblioteca de automação de navegador poderosa e versátil que nos permitirá:

Testes E2E mais robustos: Simular interações reais do usuário em diferentes navegadores, garantindo que a aplicação funcione como esperado em diversos ambientes.

Cobertura de Acessibilidade: Verificar se a aplicação atende aos padrões de acessibilidade, tornando-a mais inclusiva para todos os usuários.

Execução rápida e confiável: O Playwright é conhecido por sua velocidade e confiabilidade, o que agilizará nosso processo de testes.

Issues Relacionadas

Fixes: #501 (closed)

Como Pode Ser Testado?

  1. Antes de começar usando o terminal navegue até a pasta dos webcomponentes

  2. Acesse a branch vinculada a esse merge request (feat/playwright-testing)

    git checkout feat/playwright-testing

  3. Verifique a instalação: Certifique-se de que o Playwright foi instalado corretamente executando npx playwright --version no terminal.

  4. Se não estiver instalado execute o comando npm install na raiz do projeto. Antes de executar os comandos que executam os testes execute o comando para subir o site npm run dev:site

  5. Execute os testes: Rode os testes E2E e de acessibilidade com o comando npm run test.playwright para verificar os testes executando no terminal.

  6. Execute os testes: Rode os testes E2E e de acessibilidade com o comando npm run test.playwright.ui para verificar os testes executando na ferramenta visual do playwright ( automaticamente ela abre ).

Analise os resultados: Verifique se todos os testes passaram com sucesso. Se houver falhas, analise os relatórios gerados pelo Playwright para identificar a causa do problema.

Navegue pela aplicação: Explore a aplicação manualmente, simulando diferentes cenários de uso para garantir que a funcionalidade e a acessibilidade não foram afetadas.

Benefícios esperados:

Melhoria na qualidade e confiabilidade dos testes E2E e de acessibilidade. Maior agilidade no processo de desenvolvimento e entrega de novas funcionalidades. Redução do risco de introduzir problemas de acessibilidade na aplicação.

Critérios de 'Pronto'

Os critérios abaixo servem como um guia para garantir que uma issue esteja pronta para ser considerada finalizada e um Merge Request possa ser criado. Nem todos os itens são aplicáveis a todas as issues, portanto, remova ou adicione conforme necessário para a issue em questão.

Componentes

  • Análise do componente realizada
  • Comentários desnecessários removidos
  • Todas as partes do componente (descrição, eventos, props, métodos, slots etc.) documentadas
  • Testes do build da lib e wrappers executados
  • Documentação gerada automaticamente inclui todas as informações necessárias
  • Comportamento idêntico ao GovBR-DS
  • Visual idêntico ao GovBR-DS
  • Testes unitários passando
  • Testes E2E passando
  • Testes de regressão visual passando
  • Testes de acessibilidade passando
  • Eventos testados no ambiente de desenvolvimento
  • Exemplos para o site criados na pasta pages
  • Documentação sobre 'como migrar' criada

Site

  • Sem links quebrados
  • Build executado com sucesso
  • Sem erros de ortografia
  • Página relacionada à mudança foi atualizada
  • Página segue o padrão das demais

Markdown

  • Markdown segue os padrões do projeto

Lints

  • Códigos e conteúdos passam nos lints
  • Commits seguem os padrões definidos pelo projeto e descrevem claramente as mudanças realizadas no projeto
    • Lembre-se de usar os tipos corretos, definir os escopos e, preferencialmente, fornecer descrições breves e longas explicando todas as alterações feitas
    • Use o escopo 'no-release' para que o commit seja ignorado pelo semantic-release
Edited by Matheus Monteiro

Merge request reports