Cypress Flake Fixer

Audite uma suíte Cypress existente em busca de padrões de código que causam falhas intermitentes e corrija-os sem mascarar o problema com retentativas, tempos limite mais longos ou force: true.

Quando Usar Esta Habilidade

• Uma especificação Cypress passa localmente e falha no CI, ou falha uma vez a cada poucas execuções
• A suíte contém cy.wait(<number>), { force: true }, ou testes que só passam em ordem
• Erros mencionam "detached from the DOM", "timed out retrying", ou um assunto que "is no longer attached"
• O projeto está atualizando o Cypress entre versões principais (12 a 16)
• É solicitada uma revisão do código de teste do Cypress

Para escrever novos testes Cypress do zero, os padrões de codificação são suficientes. Esta habilidade é para diagnosticar e reparar uma suíte existente.

Pré-requisitos

• Node.js 18 ou posterior para executar o scanner (ele não tem dependências e não precisa do Cypress instalado)
• A versão do Cypress, lida a partir de package.json. As correções diferem por versão principal

Fluxo de Trabalho

1. Escanear

node ./scripts/scan-cypress.mjs <project-root>
node ./scripts/scan-cypress.mjs <project-root> --json          # machine-readable
node ./scripts/scan-cypress.mjs <project-root> --strict        # add low-confidence rules
node ./scripts/scan-cypress.mjs cypress/e2e/checkout.cy.ts     # one file

O scanner lê a versão do Cypress a partir do package.json mais próximo e classifica as APIs removidas como error quando a versão principal instalada já as rejeita e warn quando elas quebram na atualização. Execute --list-rules para o catálogo.

As descobertas são heurísticas. Abra cada local e confirme antes de editar.

2. Medir antes de mudar qualquer coisa

Quando o objetivo é corrigir uma especificação instável específica, registre com que frequência ela falha primeiro. Sem uma linha de base, não há como distinguir uma correção da sorte.

for i in $(seq 1 20); do npx cypress run --spec "cypress/e2e/checkout.cy.ts" --quiet || echo "FAIL $i"; done

Uma especificação que falha 1 em 10 execuções precisa de cerca de 30 execuções limpas após a correção antes que a correção seja crível.

3. Corrigir nesta ordem

Código antes e depois para cada regra está em references/anti-patterns.md. Substituições para APIs removidas estão em references/removed-apis.md. Leia a seção para a regra que está sendo corrigida; não carregue ambos os arquivos antecipadamente.

4. Substituir cada espera corrigida pela condição que ela representava

Não exclua uma cy.wait(n) ou a troque por um palpite. Descubra o que o atraso cobria:

5. Verificar

1. Execute a especificação alterada sozinha, depois repita-a pelo menos tantas vezes quanto a execução de linha de base.
2. Execute o scanner novamente e compare as contagens por regra.
3. Execute a suíte completa uma vez para capturar a dependência de ordem exposta pela mudança.

Regras para a própria correção

• Altere apenas o código do teste. Se o teste expõe um bug na aplicação (envio duplo, falta de estado de carregamento, corrida na UI), relate-o em vez de contorná-lo.
• Não aumente defaultCommandTimeout, adicione retries, ou adicione { force: true } para fazer um teste passar. Cada um converte uma falha visível em uma mais lenta ou oculta.
• Não substitua cy.wait(2000) por cy.wait(5000), ou por .should('exist') em um elemento que já estava presente.

…