Escolha jornadas que merecem atravessar o navegador
Use E2E para poucos fluxos críticos: autenticação, conclusão de uma ação principal ou confirmação de um resultado que depende de várias camadas. Testar toda regra pela UI torna a suíte lenta e difícil de diagnosticar. Regras de domínio pertencem a testes unitários; APIs e persistência podem ser verificadas em testes funcionais ou de integração mais focados.
Cypress é uma ferramenta para aplicações web, não uma substituição para testes de backend .NET. Seu navegador valida a interação da interface com o sistema publicado no ambiente de teste.
Seletores claros e orientados ao usuário
Prefira localizar elementos por papel acessível e nome, ou por atributos de teste estáveis quando a semântica não for suficiente. Evite seletores dependentes da estrutura DOM ou de classes de estilo que mudam durante uma reformulação. Seletores acessíveis também incentivam a interface a expor nomes compreensíveis para tecnologias assistivas.
describe('confirmação de pedido', () => {
it('confirma um pedido com itens', () => {
cy.visit('/pedidos/novo');
cy.findByRole('textbox', { name: /código do produto/i })
.type('ITEM-42');
cy.findByRole('button', { name: /adicionar item/i }).click();
cy.findByRole('button', { name: /confirmar pedido/i }).click();
cy.findByRole('status')
.should('contain.text', 'Pedido confirmado');
});
});O exemplo depende dos comandos de Testing Library para Cypress e dos nomes acessíveis definidos pela aplicação. Ajuste os seletores ao contrato real da interface; não adicione uma biblioteca sem avaliar a configuração do projeto.
Espere por condições, não por tempo arbitrário
Cypress repete consultas e assertions durante um período configurado, o que ajuda a esperar pela condição observável. Evite wait(5000) como sincronização genérica: em máquinas rápidas desperdiça tempo e em máquinas lentas pode continuar falhando. Para uma chamada específica, espere pela requisição interceptada ou por uma mudança de estado visível.
Não masque falhas com retries excessivos nem transforme um teste instável em “flaky” tolerado. Reproduza a causa: corrida de dados, dependência externa, timeout, seletor instável ou espera pela condição errada.
Dados e isolamento de cada teste
Um teste deve poder rodar sozinho e em qualquer ordem. Crie ou restaure dados de teste por uma API administrativa segura, fixture versionada ou banco descartável; evite depender de uma conta compartilhada que outro job pode alterar. Limpe os efeitos ou gere identificadores únicos e previsíveis.
Não inclua credenciais reais em scripts ou screenshots. Use segredos do ambiente de CI com escopo mínimo e dados sintéticos. Se a jornada envolve provedor externo, substitua ou controle a fronteira para manter o teste repetível, preservando outros testes que validem a integração.
Use a API sem tornar o teste apenas um teste de API
Cypress pode preparar dados por requisições HTTP, interceptar respostas e observar rede. Isso é útil para setup e cenários de erro. Mantenha pelo menos as interações que justificam o E2E no navegador: navegação, entrada e resultado visível. Se todo comportamento é interceptado, o teste pode validar o script da interface sem testar a integração real.
Execute no CI e investigue falhas
Execute a suíte contra uma versão controlada do app, guarde screenshots e vídeos quando forem úteis e associe falhas ao commit e ao ambiente. Paralelize apenas quando dados e serviços permitirem isolamento. Defina uma suíte pequena para feedback rápido e deixe fluxos mais caros para uma etapa apropriada.
Para escolher quais comportamentos cobrir, veja testes funcionais e o guia de testes de software. A integração do backend pode ser verificada com WebApplicationFactory e containers.