Skip to main content

Tests de bout en bout

Buts principaux des tests de bout en bout :​

Validation du flux utilisateur complet :​

  • Les tests E2E simulent des actions réelles qu'un utilisateur pourrait effectuer, telles que la connexion, la recherche, l'achat d'un produit, etc. Ils vérifient que l'ensemble du processus fonctionne correctement d'une page ou d'une interaction à l'autre.

Vérification de l'intégration entre les différents composants :​

  • Les tests E2E s'assurent que tous les composants d'une application (interface utilisateur, backend, base de données, API) interagissent correctement entre eux. Cela inclut la validation des interactions entre le frontend et le backend.

Détection des erreurs globales :​

  • Ces tests peuvent identifier des problèmes d'intégration qui pourraient ne pas apparaître avec des tests unitaires ou d'intégration plus localisés. Par exemple, un changement dans une API backend pourrait casser un flux utilisateur complet sans qu'aucun test unitaire ne le détecte.

Simulation de scénarios réels :​

  • Ils permettent de simuler des scénarios utilisateurs tels que la saisie de formulaires, la navigation sur plusieurs pages, l'envoi de données, ou encore des tests de performance pour voir si l'application réagit bien sous charge.

Validation des interfaces utilisateur :​

  • Les tests E2E permettent aussi de vérifier que l'interface utilisateur fonctionne comme prévu, qu'elle réagit correctement aux actions de l'utilisateur et que l'expérience est conforme aux attentes.

Suivi des tests par module (dashboard)​

Un dashboard de suivi des tests E2E recense, module par module, l'état des tests Playwright. Il est pensé comme complément du dashboard des artefacts (qui suit, lui, la publication des modules sur GitHub Packages) :

➡️ Ouvrir le dashboard des tests E2E

Chaque module y est présenté avec :

  • un statut : passing, failing, partiel, en attente (specs écrites mais pas encore exécutées en CI) ou à faire (aucune spec) ;
  • le détail des specs (*.spec.ts) et le nombre de tests ;
  • les liens vers le rapport et l'exécution CI quand ils existent.

Où vivent les tests​

Les tests Playwright sont dans le dépôt open-ent/open-ent-frontend, sous apps/open-ent-e2e/src/modules/NN_<module>/ — un dossier numéroté par module fonctionnel (01_actualites, 02_agenda, 10_cours_wiki, 14_evaluations, 35_reservation_ressources…), chaque *.spec.ts étant un scénario. Les tests sont rejoués par profil utilisateur (enseignant, élève, chef d'établissement…) via les projects Playwright.

Lancer les tests et régénérer le dashboard​

Le script apps/open-ent-e2e/run-tests.sh exécute la suite, accumule les rapports (blobs) et régénère static/e2e-results.json :

cd apps/open-ent-e2e
./run-tests.sh --project=enseignant      # un profil
./run-tests.sh --project=eleve --grep Blog
./run-tests.sh --merge                   # rapport HTML + dashboard JSON (cumul)

À chaque exécution, les blobs accumulés sont fusionnés puis transformés par scripts/build-dashboard-json.mjs, qui regroupe les résultats par dossier de module et écrit le fichier consommé par le dashboard (open-ent/docs/static/e2e-results.json). Le même script tournera dans une CI Playwright (le run_url est renseigné automatiquement depuis les variables GITHUB_*).

Schéma du fichier e2e-results.json​

{
  "generated_at": "AAAA-MM-JJ",
  "source": { "repo": "open-ent/open-ent-frontend", "tool": "Playwright",
              "run_url": null, "report_url": null },
  "modules": [
    {
      "name": "Réservation de ressources",
      "folder": "35_reservation_ressources",
      "section": "apps",
      "e2e_app": "35_reservation_ressources",
      "artifact": "rbs",
      "status": "passing | failing | partial | pending",
      "totals": { "passed": 3, "failed": 0, "skipped": 0, "total": 3 },
      "specs": [
        { "file": "09_synchronisation_agenda.spec.ts",
          "title": "…", "tests": 3, "status": "passing" }
      ]
    }
  ]
}

Un module dont aucune spec n'a encore été exécutée (blobs absents) reste au statut pending. Le champ artifact fait le lien avec le module correspondant du dashboard des artefacts.

Note CI inter-dépôts : les tests vivent dans open-ent-frontend tandis que la doc (et e2e-results.json) est dans open-ent. En local, le script écrit directement dans la doc voisine ; en CI, l'étape qui régénère le JSON doit le committer/publier vers le dépôt open-ent (ou la doc le récupère comme artefact).