batchCooking/apps/web/cypress/e2e/user-preferences.feature
Nicolas 20d52aee2d feat(web): migre les specs Cypress vers Cucumber/Gherkin
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.
2026-08-19 09:42:29 +02:00

31 lines
1.3 KiB
Gherkin

Feature: User preferences (theme)
As a signed-in user
I want to switch between system/light/dark theme
So that the app matches my preference, applied immediately
Background:
Given I am signed in as "Alice" "Martin"
Scenario: Shows SYSTEM selected by default
Given my saved theme preference is "SYSTEM"
When I visit "/parametres/preferences-utilisateur"
Then the radio "Système" should be checked
And the radio "Clair" should not be checked
And the radio "Sombre" should not be checked
And the page should have no theme override
Scenario: Shows the previously saved theme selected, and applies it to the document
Given my saved theme preference is "DARK"
When I visit "/parametres/preferences-utilisateur"
Then the radio "Sombre" should be checked
And the page theme should be "dark"
Scenario: Switching theme autosaves and applies immediately, no explicit save button
Given my saved theme preference is "SYSTEM"
And updating the theme preference will succeed
When I visit "/parametres/preferences-utilisateur"
Then I should not see "Enregistrer"
When I click the radio "Clair"
Then the theme update request should have been made with theme "LIGHT"
And I should see "Enregistré "
And the page theme should be "light"