Como você decide o que testar num codebase de frontend, e com o quê?

Teste comportamento no nível em que o usuário experimenta. Testes de componente que renderizam um componente e interagem por texto visível e papéis pegam mais bugs por unidade de esforço; testes unitários puros servem para lógica como formatação e reducers; um conjunto pequeno de testes ponta a ponta cobre as jornadas críticas como cadastro e checkout. Evite testes que afirmam sobre detalhes de implementação, já que quebram a cada refactor sem pegar regressões reais.

Minha regra é que um teste deve falhar quando o comportamento quebra e sobreviver a um refactor. Então a maioria dos meus testes renderiza um componente e o dirige como um usuário faria, achando elementos por papel e label em vez de test ids ou nomes de classe, o que significa que a acessibilidade do componente também é exercitada. Lógica pura como um formatador de datas ou um reducer ganha testes unitários simples, porque são baratos e rápidos. Depois uma suíte ponta a ponta pequena em Playwright sobre as jornadas que custam dinheiro se quebrarem: cadastro, login, checkout. Chamadas de rede são interceptadas na fronteira com um mock server em vez de mockar a função fetch, para o teste cobrir meu código de requisição real. O que evito são testes de snapshot grandes, porque ninguém revisa um diff de duzentas linhas e eles são aceitos às cegas, e qualquer coisa que afirme sobre estado interno. A outra coisa em que insisto é que testes ponta a ponta rodem contra um ambiente com dados semeados, já que dados compartilhados instáveis são o que faz times começarem a ignorar builds vermelhos.