O que realmente precisa de testes de UI
O fluxo funciona de ponta a ponta. O usuário consegue ir da intenção ao resultado. Nada abaixo da interface consegue responder a isso.
O estado ao longo das etapas. Algo definido em uma tela é respeitado na tela seguinte. É aqui que os defeitos reais se concentram.
O que é dito ao usuário corresponde ao que aconteceu de fato. Uma mensagem de sucesso sem nenhum registro salvo é a mentira mais comum que um aplicativo conta.
O que não pertence a um teste de UI
Regras de validação
Passar cada combinação de entrada inválida pelo navegador é lento e frágil.
Verifique uma na UI e o resto na API.
Cálculos
Um teste unitário responde isso em milissegundos e com uma mensagem de falha melhor.
Preparação de dados
Clicar por cinco telas para criar uma massa de dados é lento e quebra por motivos que não têm nada a ver com o que você está testando.
Dimensionando a suíte
Duas regras úteis. Cubra os fluxos pelo quão silenciosamente eles falhariam, e não pela importância, porque fluxos importantes são observados e os silenciosos não. E pare de adicionar quando o custo de manutenção começar a consumir o tempo que você estava economizando, o que acontece antes do que a maioria dos times imagina.
Os três hábitos
Âncoras estáveis, não caminhos de CSS. Elimina a maior parte das quebras causadas por redesigns.
Espere por estado, não por tempo. Elimina a maior parte da instabilidade.
Valide aquilo que um recarregamento da página confirmaria. Elimina a falsa confiança de uma mensagem de sucesso.
Empurrar um teste uma camada para baixo, na prática
O conselho de mover verificações para baixo da interface é fácil de aceitar e vago na hora de aplicar, então veja como ele fica em um exemplo real.
Você tem um teste de navegador que preenche um formulário de cadastro com quatorze entradas inválidas diferentes e confere a mensagem de erro em cada uma delas. Ele leva quatro minutos, quebra sempre que o layout do formulário muda e quase não diz nada sobre o navegador.
Troque-o por um teste de navegador que envia uma única entrada inválida e confirma que um erro é exibido ao usuário, mais treze testes de API que verificam as regras de validação diretamente. O teste de navegador agora responde a uma pergunta de navegador, as regras são cobertas de forma mais rápida e mais precisa, e uma mudança de validação não exige mais mexer em nada que seja renderizado.
A parte que a disciplina não resolve
Seletores
Um redesign que não muda nada funcional deixa a suíte vermelha.
É para onde vai a maior parte do tempo de manutenção.
Esperas
Atrasos fixos são lentos e ainda assim instáveis. Esperas corretas precisam saber o que esperar.
A maior parte da instabilidade vem daqui.
Cobertura escrita à mão
Você cobre o que alguém escreveu, ou seja, os fluxos interessantes, e não os que quebram.
O terceiro é estrutural. Uma cobertura limitada pelo tempo de quem escreve os testes vai ficar para trás de um produto cujo código chega cada vez mais de um agente. Passos baseados em intenção e cobertura gerada resolvem essa parte.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
O dashboard cobre o mesmo terreno para quem não quer instalar nada localmente, e toda a superfície de comandos está no repositório da CLI.
Conecte o repositório pelo dashboard e as execuções partem do deploy que você já gera, ou, em vez disso, adicione um passo ao seu próprio fluxo de trabalho.
O que a TestSprite cobre em cada camada
Fluxos no navegador, onde só um navegador pode responder, e a camada de API por baixo, no mesmo projeto. É isso que torna o conselho de empurrar para baixo algo prático, e não apenas uma aspiração: as regras de validação passam para casos de API que rodam em segundos, e um caso de navegador verifica se o formulário está ligado a elas.
Os dois são gerados a partir do seu produto e refinados em linguagem simples, e os passos no navegador são intenções em vez de seletores, então a suíte sobrevive a redesigns que não mudam nada funcional.
O que você acaba tendo é uma suíte de navegador pequena o bastante para as pessoas confiarem nela, cobrindo as jornadas que importam, com as regras e os casos de borda cobertos mais rapidamente uma camada abaixo.
Quantos testes de UI são o número certo?
O suficiente para cobrir as jornadas que você teria vergonha de quebrar, escolhidas pelo quão silenciosamente elas falhariam. Empurre todo o resto uma camada para baixo.
Devemos testar todas as telas?
Não. Teste fluxos, não telas. Uma tela sem nenhum fluxo passando por ela raramente justifica um teste de navegador.
E a acessibilidade?
Vale automatizar as verificações mecânicas, e o resto precisa de revisão humana. É uma preocupação separada, com ferramentas próprias.
A cobertura entre navegadores é necessária?
Depende das suas métricas de acesso. Muitos times rodam uma suíte completa em um navegador e uma suíte de smoke nos demais, o que costuma ser a troca certa.
Quando os testes de UI devem rodar?
A cada pull request. Qualquer frequência menor faz com que uma falha aponte para um lote de mudanças em vez de uma só.
Teste fluxos na UI e todo o resto abaixo dela.
Os testes de UI devem cobrir fluxos de ponta a ponta, o estado ao longo das etapas e se o que é dito ao usuário corresponde ao que aconteceu. Validação, cálculos e preparação de dados pertencem a uma camada abaixo, onde são mais rápidos e mais fáceis de diagnosticar.