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, répartis en deux suites indépendantes qui alimentent toutes les deux le même dashboard de suivi :

apps/open-ent-e2e/src/modules/NN_<module>/ — une application ENT par dossier numéroté (01_actualites, 02_agenda, 10_cours_wiki, 14_evaluations, 35_reservation_ressources…), rejouée contre http://localhost:8090 (ou l'URL cible), par profil utilisateur (enseignant, élève, chef d'établissement…) via les projects Playwright. Section apps dans e2e-results.json.
apps/dashboard-e2e/src/modules/NN_<domaine>/ — les écrans du dashboard d'administration Next.js (ex. 03_admin : gestion des établissements, sauvegarde, connexions PMB…), rejouée contre http://localhost:3001 (ou l'URL cible). Section dashboard dans e2e-results.json.

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 script accepte les rapports JSON des deux suites (--in pour open-ent-e2e, --in-dashboard pour dashboard-e2e) et fusionne leurs univers de modules dans le même fichier — c'est scripts/publish-e2e-reports.sh qui orchestre la fusion des blobs de chaque suite puis cet appel. Le run_url est renseigné automatiquement depuis les variables GITHUB_* en CI.

Reporter blob obligatoire

Le script ne peut fusionner que des résultats produits avec --reporter=blob,... — un run lancé avec --reporter=list seul (ou tout autre reporter sans blob) réussit mais ne laisse rien à consolider : ses résultats resteront invisibles sur /e2e-dashboard, sans erreur visible. C'est la cause d'un bug réel constaté ici : l'étape dashboard-e2e du workflow deploy-e2e-to-ovh.yml n'utilisait que --reporter=list.

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. section vaut apps (open-ent-e2e) ou dashboard (dashboard-e2e) — c'est ce qui détermine sous quel bandeau (« Applications » / « Dashboard d'administration ») le module s'affiche sur /e2e-dashboard.

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).

CI de publication (`deploy-e2e-to-ovh.yml`)

Le workflow deploy-e2e-to-ovh.yml (dépôt open-ent) est celui qui alimente réellement /e2e-dashboard en production : il exécute les deux suites contre une vraie URL (prod ou recette), consolide, puis publie le rapport HTML et e2e-results.json sur OVH.

Déclenchement manuel uniquement (workflow_dispatch) — jamais sur push. Renseigner ent_base_url/dashboard_base_url avec l'URL réelle à tester (une URL localhost n'est pas joignable depuis le runner GitHub) ; run_open_ent_e2e/run_dashboard_e2e/ lilit_profile permettent de limiter le périmètre d'un run.
Secrets requis : E2E_ADMIN_USER/E2E_ADMIN_PASS (compte super-admin de l'environnement ciblé — pas nécessairement tom.mate/password, qui ne sont que les identifiants du compte de démo local), et si lilit_profile=true, E2E_LILIT_USER/E2E_LILIT_PASS. Sans ces secrets, les étapes de connexion échouent silencieusement (continue-on-error: true sur chaque étape de test — un run peut donc se terminer "success" sans qu'aucun test n'ait réellement pu se connecter).

Lancer manuellement une exécution :

gh workflow run "🧪 E2E — Tests & publication sur OVH (open-ent-test)" -R open-ent/open-ent \
  --ref develop \
  -f ent_base_url="https://www.mon-instance.fr" \
  -f dashboard_base_url="https://www.mon-instance.fr" \
  -f run_open_ent_e2e=true -f run_dashboard_e2e=true -f lilit_profile=true

⚠️ --ref détermine le code réellement exécuté (workflow et specs) : sans lui, gh utilise la branche par défaut du dépôt, pas forcément celle qui contient les derniers correctifs.

Suivi des tests des modules patchés (`open-ent-mods`)

En complément de la suite frontend ci-dessus, le dépôt open-ent/open-ent-mods possède sa propre suite e2e (≈ 122 specs, un *.spec.ts par module dans tests/) et son dashboard dédié :

➡️ Ouvrir le dashboard des tests E2E — Modules

Bascule local ↔ recette (variables d'environnement)

Contrairement à la suite frontend (URL centralisée dans use.baseURL), chaque spec mods ouvre sa propre session sur /auth/login. L'URL cible et les identifiants sont désormais injectables par variable d'environnement, avec un fallback sur les valeurs de développement (donc l'exécution locale reste inchangée) :

Variable	Rôle	Fallback (local)
`ENT_URL`	URL de l'instance ENT testée	`http://localhost:8090`
`ENT_USER` / `ENT_PASSWORD`	compte enseignant (utilisateur standard des specs)	`fathallah.adams001`
`ENT_ADMIN_USER` / `ENT_ADMIN_PASS`	compte super-admin (actions d'administration)	`tom.mate`

CI : deux niveaux (`playwright.yml`)

Le workflow .github/workflows/playwright.yml comporte deux jobs :

smoke — sur chaque push/pull_request : vérifie qu'une recette en ligne répond, authentifie et sert le portail (smoke-ci.spec.ts uniquement).
full-e2e — à la demande (workflow_dispatch) : lance toute la suite contre la recette (ENT_URL), sur le modèle du dashboard frontend. Les 4 specs dashboard-embed-* (qui exigent en plus un dashboard Next.js sur :3001, via DASH_URL) sont exclues tant que ce dernier n'est pas fourni.

Pré-requis d'exécution sur la recette : les comptes ENT_USER (enseignant) et ENT_ADMIN_USER (super-admin) doivent y être provisionnés avec les bons rôles et droits d'applications (cf. gestion des accès du dashboard). Sur cd16, tom.mate est déjà super-admin ; il reste à provisionner le compte enseignant.

Publication du dashboard mods

Le dashboard /e2e-dashboard-mods charge au runtime le fichier static/mods-e2e-results.json (même schéma que e2e-results.json, avec un champ source.repo = open-ent/open-ent-mods). Ce fichier est régénéré par le job full-e2e à partir du rapport Playwright, puis publié sur OVH sous /doc/open-ent-dev/mods-e2e-results.json — comme e2e-results.json côté frontend.

Buts principaux des tests de bout en bout :​

Validation du flux utilisateur complet :​

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

Détection des erreurs globales :​

Simulation de scénarios réels :​

Validation des interfaces utilisateur :​

Suivi des tests par module (dashboard)​

Où vivent les tests​

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

Schéma du fichier e2e-results.json​

CI de publication (deploy-e2e-to-ovh.yml)​

Suivi des tests des modules patchés (open-ent-mods)​

Bascule local ↔ recette (variables d'environnement)​

CI : deux niveaux (playwright.yml)​

Publication du dashboard mods​