Testes em Frontend Moderno: Estado, Async, Rede e UI

O problema

Teste de frontend vira bagunça rápido porque muita coisa acontece ao mesmo tempo:

• estado local
• estado remoto
• renderização
• evento de usuário
• request
• loading
• retry
• erro

Se você não separa esses pedaços mentalmente, a estratégia degrada.

Aí aparecem dois extremos ruins:

• teste minúsculo demais, que confirma detalhe interno e não protege fluxo
• teste gigante demais, que tenta cobrir tudo e fica lento, frágil e caro

Modelo mental

Pense assim:

frontend moderno não é “só UI”. É coordenação entre estado, tempo, rede e interação.

Por isso a pergunta principal não deveria ser:

“Qual ferramenta de teste vamos usar?”

Melhor perguntar:

“Qual risco eu quero reduzir neste pedaço do frontend?”

Exemplos:

• regra de transformação de dados
• componente renderizando estados corretos
• integração com request e cache
• fluxo completo do usuário

Cada uma dessas coisas pede um nível de teste diferente.

Quebrando o problema

Estado puro costuma pedir teste mais barato

Se há uma função que:

• filtra resultado
• calcula total
• decide status
• transforma resposta da API

isso geralmente não precisa de DOM nem navegador.

Teste simples e direto costuma bastar.

É barato, rápido e ajuda muito quando a lógica começa a crescer.

Integração de componente é onde muita confiança real aparece

Boa parte do valor no frontend está em verificar:

• loading aparece quando deve
• erro aparece quando deve
• sucesso atualiza a tela
• ação do usuário dispara o fluxo certo

Isso normalmente pede componente renderizado com suas dependências principais, mas sem transformar tudo em e2e.

É aqui que muita equipe amadurece de verdade.

Porque para de testar só função solta e passa a testar comportamento visível.

Rede precisa ser tratada com critério

Tem time que mocka tudo de forma tão artificial que o teste perde contato com o comportamento real.

Tem time que usa rede real demais e compra lentidão e instabilidade.

O ponto de equilíbrio costuma ser:

• simular rede no nível do contrato esperado
• testar sucesso, erro e loading
• reservar ambiente real para poucos fluxos essenciais

Ou seja, não é “mock nunca” nem “mock sempre”.

É controlar o que interessa sem mentir sobre o sistema.

Async muda o jeito de observar o teste

No frontend moderno, muita falha vem de uma expectativa síncrona sobre algo assíncrono.

Por exemplo:

• teste afirma antes de a tela atualizar
• clica e valida antes da request terminar
• espera texto errado em vez de esperar estado observável

O problema aqui não é só ferramenta.

É modelo mental.

O teste precisa acompanhar o ritmo real do sistema.

E2E tem espaço, mas não substitui o resto

E2E é ótimo para responder:

• o fluxo principal funciona?
• integração real entre partes críticas está viva?
• o caminho de negócio mais importante ainda fecha?

Mas é caro usar e2e para tudo.

Quando a equipe tenta jogar toda confiança para o topo da pirâmide, o custo volta em lentidão, flakiness e manutenção.

Exemplo simples

Imagine uma tela de busca de pedidos.

Ela tem:

• input de busca
• loading
• lista de resultados
• estado vazio
• mensagem de erro

Uma estratégia razoável pode ser:

1. testar a função que normaliza filtro e paginação
2. testar o componente exibindo loading, sucesso, vazio e erro
3. testar que digitar e submeter dispara a request esperada
4. ter um e2e cobrindo o fluxo principal de busca

Estratégia ruim seria:

• testar tudo só por e2e

ou:

• testar só função isolada e declarar vitória

Nenhum dos extremos protege bem o produto.

Erros comuns

• Escrever teste acoplado a state, prop ou estrutura interna sem necessidade.
• Ignorar estados de erro e loading porque o “caso feliz” já passou.
• Fazer mock tão artificial que o fluxo real deixa de existir.
• Colocar confiança demais em e2e para cobrir buracos de estratégia.
• Usar seletor frágil e culpar a ferramenta quando o teste quebra.

Como um senior pensa

Quem tem mais repertório olha para frontend e pensa em camadas de risco.

Não tenta vencer no volume.

Tenta posicionar melhor a confiança.

Perguntas comuns de alguém mais forte:

• qual parte é lógica pura?
• qual parte precisa de DOM?
• qual parte depende de contrato de rede?
• qual fluxo merece e2e porque tem alto impacto?

Isso dá uma suíte mais barata de manter e muito mais útil.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver se você pensa em estratégia, não só em ferramenta.

Resposta fraca:

“Eu testaria com unit, integration e e2e.”

Resposta melhor:

“Eu separaria a lógica de estado da interação visível. Regras de transformação eu testaria de forma isolada. Estados importantes da UI eu validaria com teste de componente. Fluxos críticos de negócio eu deixaria cobertos por poucos e2e. E trataria loading, erro e sucesso como parte central da estratégia, não como detalhe.”

Isso mostra:

• noção de custo
• noção de risco
• entendimento de frontend real

Testar frontend bem é escolher onde cada tipo de confiança vale mais.

Quando tudo vira e2e, a suíte fica cara. Quando tudo vira unit, o produto fica desprotegido.