As três falhas de tempo de execução que o teste de aplicações web precisa cobrir
Estado residual
Um modal fecha e deixa a rolagem travada. Um filtro continua aplicado onde não faz sentido.
Só aparece na segunda interação, então uma reprodução do zero nunca encontra.
Renderização antes dos dados
A página é desenhada, o fetch é resolvido, nada re-renderiza.
Costuma ser intermitente, e é por isso que sobrevive à revisão.
O segundo usuário
Suposições de propriedade e de visibilidade construídas a partir da própria sessão de quem desenvolveu.
Funciona perfeitamente para todo mundo que construiu a funcionalidade.
A verificação que pega a maior parte disso
Faça a ação duas vezes, como dois usuários diferentes, com um reload no meio. Esse único padrão atinge as três categorias, e é justamente o que o teste manual pula porque a primeira tentativa funcionou.
O que verificar
Algo que um reload confirmaria. Uma mensagem de sucesso não é prova de que alguma coisa foi persistida. Busque o dado de volta.
A ausência do que não deveria estar lá. Depois de excluir, a linha sumiu. Depois de sair da conta, os dados não ficam visíveis.
O comportamento para outra pessoa. A segunda conta não consegue ver os registros da primeira.
Onde entra o desenvolvimento local
O trabalho em aplicações web acontece no localhost muito antes de qualquer deploy, e uma verificação que só funciona contra uma URL pública chega tarde demais para mudar o que você constrói. O CLI consegue criar um túnel para uma aplicação rodando na sua própria máquina nas execuções de frontend, então a verificação fica disponível enquanto você ainda está trabalhando. Os detalhes estão no repositório do CLI.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
O dashboard cobre o mesmo terreno para quem não quer uma instalação local.
O teste das duas abas
Existe uma verificação manual que vale a pena fazer antes de qualquer release e que encontra mais do que custa, e quase ninguém faz: abra a aplicação em duas abas.
Faça alguma coisa na primeira e depois olhe a segunda. A maioria das aplicações web se comporta mal aqui de alguma forma, e esse mau comportamento é informativo. Uma lista que não atualiza normalmente não é problema. Uma ação desatualizada que tem sucesso e sobrescreve dados mais novos é um bug de verdade. Uma sessão que desloga uma aba quando a outra renova um token é um bug de verdade. Uma atualização otimista que nunca se reconcilia é um bug de verdade.
Leva dois minutos, não precisa de ferramenta nenhuma e exercita exatamente a costura em que o estado do servidor, o estado do navegador e a expectativa do usuário discordam. Se você for adotar só um hábito desta página, adote esse.
Torne isso contínuo
Falhas de tempo de execução são justamente as que reaparecem, porque as condições que as produzem são fáceis de recriar sem querer.
O GitHub App é um webhook que você configura no dashboard do TestSprite. Ele escuta o evento de deploy que seu pipeline já produz, então nada no seu repositório muda.
GitHub Actions coloca o passo dentro do seu próprio workflow, configurado pelo terminal.
Como o TestSprite exercita a aplicação em execução
Ele abre a aplicação implantada e a usa como uma pessoa usaria, que é a única forma de enxergar estado residual, renderização antes dos dados e comportamento para o segundo usuário. Os casos são descritos em linguagem simples e gerados a partir do seu produto, e verificam coisas que um reload confirmaria, em vez de uma mensagem que o cliente renderizou.
A verificação do segundo usuário é um caso de primeira classe, não um exercício de configuração, e isso importa porque suposições de permissão são a falha com mais chance de chegar ao cliente e menos chance de ser notada por quem construiu a funcionalidade.
As verificações seguem rodando a cada mudança, então as divergências entre os três estados que um dia produziram um bug não conseguem reaparecer silenciosamente depois que a branch é mesclada.
Por que isso não aparece no code review?
Porque são propriedades de uma interação entre estado do servidor, estado do navegador e histórico. Um diff não mostra nada disso.
Dá para testar isso com testes unitários?
Em parte, com muito mock, e os mocks codificam as mesmas suposições que o código. Rodar a coisa real é o que desempata.
Como testar o segundo usuário de forma confiável?
Mantenha uma segunda conta por ambiente e rode o mesmo fluxo com as duas. É a verificação mais barata e de maior retorno no teste de aplicações web.
E os navegadores mobile?
Diferenças de viewport revelam um conjunto separado de problemas de layout e de interação. Vale cobrir os fluxos principais em tamanho mobile se você tem tráfego mobile.
Quanto disso dá para rodar localmente?
Execuções de frontend conseguem alcançar uma aplicação na sua máquina por meio de um túnel. Alvos de backend que não estão acessíveis ainda precisam de um ambiente exposto.
Faça duas vezes, como dois usuários, com um reload.
O teste de aplicações web precisa cobrir estado residual, renderização antes dos dados e comportamento para o segundo usuário, e nada disso é visível no código-fonte. Verifique o que um reload confirma, cheque a ausência do que deveria ter sumido e rode o mesmo fluxo como outra pessoa.