🎯 Intention

Écrire des bons tests Cypress permet de garantir leur fiabilité et leur rapidement. Si la suite de test est trop lente, alors l’équipe a tendance à abandonner Cypress.

<aside> ✅ Pré-requis

• Avoir vu le standard Écrire des tests de qualité </aside>

✅ Points clés

<aside> ⌛ Temps indicatif : 1h

</aside>

Etape

Visuel / Exemple

🔗 Créer une commande pour se connecter à l’application

• La connexion doit utiliser un système de cache

Raison :

Permet d’accélérer l’ensemble de la batterie de test

❌ BAD
Cypress.Commands.add('login', (username, password) => {
  cy.visit('/login')
  cy.get('[data-test=username]').type(username)
  cy.get('[data-test=password]').type(password)
  cy.get('#login').click()
  cy.url().should('contain', '/login-successful')
})

✅ GOOD
Cypress.Commands.add('login', (username, password) => {
  cy.session([username, password], () => {
    cy.visit('/login')
    cy.get('[data-test=username]').type(username)
    cy.get('[data-test=password]').type(password)
    cy.get('#login').click()
    cy.url().should('contain', '/login-successful')
  })
})

🔗 Sélectionner des éléments avec data-test

• Récupérer un élément via data-test Il est possible aussi d’utiliser data-testid

  <MonItem data-test="mon-item" data-testid="13r2f23r-12er23r23r-1e23r3223-23d2323">

• Faire une commande de sélection pour simplifier l’usage https://docs.cypress.io/guides/references/best-practices#Real-World-Example

Raison :

Permet d’éviter qu’un test échoue plus tard

source: https://docs.cypress.io/guides/references/best-practices#Selecting-Elements

• chaque it doit avoir un seul should
• chaque test doit passer en .only https://docs.cypress.io/guides/references/best-practices#Having-Tests-Rely-On-The-State-Of-Previous-Tests

❌ Erreurs type à éviter

(L’erreur type est de) VERBE + description : cas limite, mauvais résultat au lieu de résultat attendu, etc.