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.
33 lines
1 KiB
TypeScript
33 lines
1 KiB
TypeScript
import type { SafeUserProfile } from "@batch-cooking/shared";
|
|
|
|
/**
|
|
* Mutable per-scenario signed-in profile, built up across several `Given`
|
|
* steps (see common.steps.ts's "I am signed in as .../my household id
|
|
* is.../my diet id is...") before the final `cy.visit` — each step
|
|
* re-registers the `GET **\/auth/me` intercept with the updated shape, so
|
|
* only the last one (i.e. the fully assembled profile) is ever actually
|
|
* requested by the app. Reset before every scenario by the `Before` hook in
|
|
* common.steps.ts, so scenarios never leak state into one another.
|
|
*/
|
|
export let currentProfile: SafeUserProfile | null = null;
|
|
|
|
export function resetProfile() {
|
|
currentProfile = null;
|
|
}
|
|
|
|
export function buildProfile(overrides: Partial<SafeUserProfile> = {}): SafeUserProfile {
|
|
return {
|
|
id: 1,
|
|
firstName: "Alice",
|
|
lastName: "Martin",
|
|
email: "alice@example.com",
|
|
tokenVersion: 0,
|
|
houseId: null,
|
|
dietId: null,
|
|
...overrides,
|
|
};
|
|
}
|
|
|
|
export function setCurrentProfile(profile: SafeUserProfile) {
|
|
currentProfile = profile;
|
|
}
|