Seletores no Cypress: Boas Práticas e Adaptação para o Sencha ExtJS 4.2
Boas Práticas do Cypress
Segundo a documentação oficial do Cypress (https://docs.cypress.io/app/core-concepts/best-practices#How-It-Works) , a escolha correta dos seletores é fundamental para a manutenção e confiabilidade dos testes automatizados.
O que evitar:
-
Seletores frágeis como
id,classoutag -
Seletores baseados em conteúdo textual (como
cy.contains('Texto')) -
Elementos sujeitos a mudanças de estilo, estrutura ou lógica de JS
O recomendado:
A prática recomendada é utilizar atributos personalizados data-*, como data-cy, data-test ou data-testid. Esses atributos são isolados de mudanças no estilo ou comportamento da aplicação e indicam claramente que o elemento é usado nos testes.
Exemplo de boa prática:
Melhor seletor possível:
Essa abordagem torna os testes mais estáveis, legíveis e resilientes a alterações visuais ou estruturais da aplicação.
Como utilizar data-* no Cypress (Boas Práticas)
A prática recomendada pelo Cypress para selecionar elementos é usar atributos personalizados data-*, como data-cy, data-test ou data-testid. Esses atributos são adicionados diretamente no HTML da aplicação, com o único propósito de facilitar e tornar mais confiáveis os testes automatizados.
1. Adicionando o atributo no HTML
O atributo deve ser incluído no elemento que será testado. Exemplo:
Esse atributo não interfere no estilo nem no funcionamento do botão. Ele serve apenas para que os testes possam localizá-lo com precisão.
2. Selecionando no Cypress
No teste, usa-se o cy.get() com o seletor do atributo:
Esse seletor é:
-
Estável (não muda com CSS ou refatorações visuais)
-
Claro (indica explicitamente que o elemento é usado em testes)
-
Reutilizável
3. Variações aceitas
Além de data-cy, o Cypress reconhece outras convenções:
-
data-test -
data-testid
Todos funcionam da mesma forma. O mais comum é data-cy, por ser amplamente usado na documentação oficial.
Com isso acaba tendo os seguintes benefícios:
-
Evita quebra de testes após mudanças no CSS ou JS
-
Facilita manutenção e leitura dos testes
-
Deixa claro para desenvolvedores que aquele elemento é usado nos testes
Adaptação em Sistemas Legados (Sencha Ext JS)
No entanto, aplicações legadas como as desenvolvidas com Sencha Ext JS 4.2 não foram projetadas com automação de testes em mente (Como esse é o caso do ILLI). Nesses sistemas:
-
Os elementos são gerados dinamicamente.
-
Os IDs são aleatórios ou instáveis.
-
Não há suporte nativo a atributos
data-*. -
A estrutura do DOM é profundamente acoplada ao framework.
Solução adotada
Diante dessa limitação, a solução adotada é a utilização de seletores baseados em classes CSS estáveis, que são aplicadas consistentemente pelo Sencha e raramente mudam.
Para facilitar a manutenção e a reutilização desses seletores, eles são definidos em variáveis centralizadas por meio de Cypress.env().
Exemplo:
Justificativa
Embora o uso de classes CSS vá contra as boas práticas recomendadas pelo Cypress, no contexto de um sistema legado:
-
A estrutura não pode ser alterada sem risco à funcionalidade da aplicação.
-
O custo de refatoração para suportar
data-*seria elevado e arriscado. -
As classes CSS fornecem o melhor equilíbrio entre estabilidade e viabilidade de automação.
- Está sendo utilizado a criação de uma estrutura de variáveis, caso haja necessidade de alterar o CSS ter um local apenas para fazer essa alteração.
Considerações Finais
A em sumo é reconhecido que o uso de data-* seria o ideal para automação com Cypress. No entanto, dentro das limitações impostas pelo Sencha Ext JS, a adoção de seletores baseados em classes CSS específicas e padronizadas é a abordagem mais viável e segura para garantir testes confiáveis e reutilizáveis.
Nenhum comentário