Les tests e2e (apps/web/cypress/e2e/) étaient de simples specs Cypress
(.cy.ts), sans lien avec Cucumber alors qu'apps/api utilise déjà
Gherkin pour ses propres tests BDD. Intègre
@badeball/cypress-cucumber-preprocessor pour écrire les scénarios
utilisateurs en Gherkin des deux côtés, même vocabulaire.
- cypress.config.ts : specPattern sur *.feature, wiring du
préprocesseur (esbuild bundler + plugin cucumber)
- Les 11 fichiers .cy.ts sont remplacés par des paires .feature/.steps.ts
(co-localisées, même nom) — conversion complète, comportement
équivalent (mêmes intercepts, mêmes assertions)
- cypress/support/step_definitions/common.steps.ts : steps partagés
entre features (connexion, navigation, assertions génériques de
texte/URL/champ) — globaux à toute la suite, réutilisables tels quels
- cypress/support/profile.ts : profil du compte "connecté" courant,
assemblé au fil de plusieurs Given avant le premier visit/When
- README : nouvelle section "Cucumber (apps/web)" (miroir de la section
existante pour apps/api), mise à jour des références aux anciens noms
de fichiers .cy.ts (déjà obsolètes avant ce changement)
Vérification : impossible d'exécuter Cypress dans cet environnement
(crash Electron/GPU au lancement, limitation déjà documentée dans le
README — reproductible sur main, indépendante de ce changement). À la
place :
- les 447 steps Gherkin des 11 .feature ont été vérifiés
programmatiquement contre les 165 patterns de step enregistrés : 0
non résolu, 0 ambigu
- les 11 .feature parsent correctement avec le parser Gherkin officiel
(57 scénarios au total)
- tous les .steps.ts passent `biome check` (syntaxe + style) sans erreur
- CYPRESS_INSTALL_BINARY déjà géré (voir PR précédente) — le binaire est
bien présent localement (`cypress verify` OK), donc le blocage est
spécifiquement le sandbox GPU de cet environnement, pas l'installation
La vraie exécution reste à vérifier via le job `e2e` de la CI GitHub
Actions sur cette PR — c'est le chemin déjà documenté dans le README
pour cet environnement précis.
