Ecriture de scénarios de test E2E de base

Passer de la théorie à la pratique

Après avoir compris ce que sont les tests end-to-end (E2E) et découvert les outils populaires comme Cypress et Playwright, l'étape suivante est d'apprendre à structurer et écrire des scénarios de test concrets. Bien que la syntaxe exacte varie entre les outils, les principes fondamentaux de l'écriture d'un test E2E restent similaires.

L'objectif ici n'est pas de maîtriser l'API complète de Cypress ou Playwright, mais de comprendre la structure typique d'un scénario E2E de base et les étapes logiques impliquées dans sa création. Nous nous concentrerons sur la simulation d'un parcours utilisateur simple et la vérification du résultat attendu.

Anatomie d'un scénario de test E2E

Un test E2E typique suit généralement une structure en trois actes, souvent appelée "Arrange-Act-Assert" (AAA), adaptée au contexte E2E :

1. Visiter / Préparer (Arrange/Visit) : Le test commence par naviguer vers la page de démarrage du scénario ou par mettre l'application dans un état initial requis. Cela implique souvent de visiter une URL spécifique. Dans des scénarios plus complexes, cela pourrait aussi inclure la connexion d'un utilisateur ou la mise en place de données initiales (parfois via des commandes spécifiques de l'outil E2E ou des appels API préparatoires).
2. Agir (Act) : C'est la phase où le test simule les actions de l'utilisateur. Il utilise les commandes fournies par l'outil E2E pour localiser des éléments dans le DOM (boutons, champs de formulaire, liens) et interagir avec eux (cliquer, taper du texte, sélectionner une option, etc.). Cette phase peut comporter plusieurs étapes séquentielles pour représenter un parcours utilisateur complet.
3. Vérifier (Assert) : Après avoir effectué les actions, le test vérifie que l'application a réagi comme prévu. Les assertions portent sur l'état final de l'interface utilisateur ou de l'application. On vérifie par exemple que certains textes sont affichés, que des éléments sont visibles ou cachés, que l'URL a changé, ou que des attributs spécifiques sont présents sur des éléments.

Etapes clés pour écrire un scénario de base

• 1. Définir le scénario : Décrivez clairement le parcours utilisateur que vous voulez tester. Par exemple : "En tant qu'utilisateur, je veux pouvoir me connecter avec des identifiants valides et être redirigé vers mon tableau de bord."
• 2. Identifier le point de départ : Quelle est l'URL de la page où le scénario commence (ex: `/login`) ?
• 3. Localiser les éléments interactifs : Utilisez les outils d'inspection du navigateur pour identifier des sélecteurs fiables pour les éléments avec lesquels le test doit interagir (champs de saisie, bouton de connexion). Les outils E2E offrent différentes stratégies de sélection (par texte, par ID, par sélecteur CSS, par attribut `data-cy` ou `data-testid`, etc.). Privilégiez des sélecteurs robustes et moins susceptibles de changer.
• 4. Ecrire les commandes d'action : Utilisez l'API de votre outil E2E (Cypress ou Playwright) pour simuler les actions :
  • Naviguer vers l'URL (`cy.visit('/login')` ou `page.goto('/login')`).
  • Trouver un champ et y taper du texte (`cy.get('input[name=username]').type('user')` ou `page.locator('input[name=username]').fill('user')`).
  • Trouver un bouton et cliquer dessus (`cy.get('button[type=submit]').click()` ou `page.locator('button[type=submit]').click()`).
• 5. Ecrire les assertions : Utilisez les capacités d'assertion de l'outil pour vérifier le résultat :
  • L'URL a-t-elle changé ? (`cy.url().should('include', '/dashboard')` ou `expect(page).toHaveURL('/dashboard')`).
  • Un élément spécifique est-il visible sur la nouvelle page ? (`cy.get('h1').should('contain', 'Tableau de bord')` ou `expect(page.locator('h1')).toContainText('Tableau de bord')`).
  • Un message d'erreur s'affiche-t-il en cas d'échec ? (`cy.get('.error').should('be.visible')` ou `expect(page.locator('.error')).toBeVisible()`).

Exemple illustratif (Pseudo-code / Conceptuel)

Imaginons un test pour une simple application compteur avec un bouton "Incrémenter".

// Fichier de test E2E (syntaxe conceptuelle)

decrire('Test du compteur', () => {

  tester('devrait incrémenter le compteur au clic', () => {
    // 1. Visiter la page où se trouve le compteur
    visiter('/'); // Navigue vers la racine de l'application

    // 2. Agir : Localiser le bouton et cliquer
    // (Utiliser un sélecteur robuste, ex: data-testid)
    localiser('[data-testid="increment-button"]').cliquer();

    // 3. Vérifier : Le texte du compteur s'est mis à jour
    // Trouver l'élément affichant le compteur
    const compteurElement = localiser('[data-testid="count-display"]');
    // Vérifier que son texte contient '1'
    verifier(compteurElement).doitContenirLeTexte('1');

    // On pourrait cliquer à nouveau et vérifier '2'
    localiser('[data-testid="increment-button"]').cliquer();
    verifier(compteurElement).doitContenirLeTexte('2');
  });

});

Ce pseudo-code montre la logique : visiter, trouver un élément (`localiser`), interagir (`cliquer`), puis vérifier le résultat (`verifier(...).doitContenirLeTexte`). La syntaxe réelle de Cypress (`cy.visit`, `cy.get`, `.click`, `.should('contain', ...)`) ou Playwright (`page.goto`, `page.locator`, `.click`, `expect(...).toContainText(...)`) sera différente, mais suivra ce flux logique.

Conseils pour démarrer

• Commencez simple : Choisissez des parcours utilisateurs courts et critiques pour vos premiers tests.
• Concentrez-vous sur le "happy path" : Validez d'abord que le scénario nominal fonctionne correctement avant d'ajouter des tests pour les cas d'erreur.
• Utilisez des sélecteurs dédiés aux tests : Les attributs comme `data-testid` (ou `data-cy` pour Cypress) sont souvent recommandés car ils découplent vos tests des styles CSS ou de la structure exacte du DOM, rendant les tests plus résistants aux changements visuels.
• Organisez vos tests logiquement : Utilisez les blocs `describe` (ou équivalent) pour regrouper les tests liés à une fonctionnalité ou à une page spécifique.

L'écriture de tests E2E demande de la pratique et une bonne connaissance de l'outil choisi. Cependant, en suivant ces principes de base, vous pouvez commencer à construire une suite de tests E2E qui apporte une valeur significative en validant les flux essentiels de votre application React.