6 commits

Author	SHA1	Message	Date
Nicolas	8bcea74b56	fix(layout): masque l'onglet « Paramètres d'application » hors de l'app native (#107) ... Ses sections n'ont pas de sens sur le web (pas de « version installée », la vérif de mise à jour y est un no-op) et son seul réglage web-pertinent — la case « toujours rester sur le site web » — vit mieux dans le flux qu'il pilote. - `AppLayout.tsx` : `SETTINGS_ITEMS` gagne un `nativeOnly`, filtré une fois au chargement du module (`settingsNavItems`) via `Capacitor.isNativePlatform()` — l'entrée disparaît du menu Paramètres (sidebar + feuille « Plus »). - `App.tsx` : la route `/parametres/application` redirige vers `/parametres/compte` sur le web, comme le précédent `/foyer`, pour qu'un bookmark ne tombe pas sur une page orpheline. - `AppSettingsPage.tsx` : devient natif-only — la branche `webHint` et la section « rester sur le site web » sont retirées. - La case « toujours rester sur le site web » déménage sur `/telecharger` (`DownloadPage`) : page publique qu'un visiteur non connecté sur navigateur téléphone peut atteindre, et c'est exactement le flux que la préférence concerne. `localStorage` sur l'origine web publique, là où `attemptOpenNativeApp` la lit. i18n `appSettings.redirect.*` → `download.stayOnWeb.*` ; `appSettings.version.webHint` supprimée. Tests : `sidebar.cy.ts` / `app-settings-page.cy.ts` — l'entrée et la page sont absentes sur le web, la route redirige. `download-page.cy.ts` — la case « rester sur le site web » par défaut décochée, persistée au reload. Local OK (sidebar 5/5, app-settings 2/2, download 3/3). Closes #107 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-08 05:23:06 +02:00
Nicolas	e1589e63d0	feat(settings): onglet "Paramètres d'application" (#86) ... Nouvelle route /parametres/application + entrée dans SETTINGS_ITEMS (desktop et sheet mobile, un seul tableau partagé). Thème et "rejouer un tutoriel" restent inchangés dans /parametres/preferences-utilisateur (décision explicite du chantier). Le contenu affiché diffère réellement selon la plateforme, pas par simple choix cosmétique — chaque moitié de la page est inerte sur l'autre plateforme, pas juste hors-sujet : - Version installée + "Vérifier les mises à jour" (natif seulement) : useAppUpdateCheck (déjà utilisé par la bannière silencieuse existante) gagne un checkNow() qui relance la même comparaison sans attendre le throttle de 6h, réutilisant la logique existante plutôt que de la dupliquer (fetchLatestVersionResult extraite en fonction partagée). Nouveau hook useInstalledVersion (App.getInfo() natif, __APP_VERSION__ web). - "Toujours rester sur le site web" (web seulement, tout appareil) : pilote STAY_ON_WEB_PREFERENCE_KEY (déjà exporté par mobile-app-redirect.ts, ticket #84). Volontairement masqué côté natif : le WebView Capacitor tourne sur sa propre origine https://localhost, un localStorage totalement séparé de celui du vrai site web que lit attemptOpenNativeApp — modifier la préférence depuis l'app ne changerait donc jamais rien pour un visiteur mobile réel. Documenté explicitement dans le commentaire de la page pour ne pas réintroduire ce contrôle-fantôme plus tard. Couverture Cypress : nouveau app-settings-page.cy.ts (contenu web, persistance du toggle après reload) ; sidebar.cy.ts étendu pour couvrir le nouveau lien. Le déclenchement natif réel (App.getInfo(), l'appel réseau de checkNow) n'a pas de point d'entrée testable depuis un run Cypress web — même posture déjà acceptée pour useAppUpdateCheck/ UpdateBanner, la logique de comparaison pure reste couverte par version-compare.cy.tsx (inchangé). Suite complète : biome check, tsc -b --force, build, 146/146 e2e, 71/71 composants — tous verts. Closes #86 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-07 17:19:36 +02:00
kyuno053	f1fefc1f38	refactor: sépare les tests Cypress en parcours utilisateur / layout / composants (#25) ... * chore: point de départ pour le refactor des tests Cypress Sépare les tests Cypress en trois catégories, comme discuté : 1. Parcours utilisateur (cypress/e2e/) — scénarios Gherkin/Cucumber, pilotés par @badeball/cypress-cucumber-preprocessor@22.2.0 (validé sur experiment/cucumber-cypress, mergée). Ex. "En tant qu'utilisateur, je peux créer un compte". 2. Layout applicatif (nouveau dossier à définir) — specs Cypress classiques (pas de Gherkin), cy.visit() sur une vraie page, mais centrées sur la disposition/visibilité des éléments, indépendamment d'un parcours utilisateur scripté. 3. Composants génériques (cypress/component/, nouveau) — vrai Component Testing Cypress, composant React monté isolément (pas de routeur, pas de backend). Composants concernés aujourd'hui : components/ui/{Checkbox,Radio,Dialog}.tsx. Premier pas : mise en place de l'infra Component Testing (config + devServer Vite + adapter React 18), validée sur un composant simple avant de construire le reste. * feat(web): infra Cypress Component Testing, premier test sur CheckboxOption Étape 1 du refactor (voir PR) : met en place le vrai mode Component Testing de Cypress, séparé de l'e2e — monte un composant React isolé (pas de routeur, pas de backend), pour tester les composants génériques (components/ui/) indépendamment de tout parcours utilisateur. - cypress.config.ts : nouveau bloc `component` (devServer Vite, réutilise vite.config.ts de l'appli — même plugin React, même Sass). Le hook GPU-disable est factorisé (`disableGpu`) puisque e2e et component ont chacun leur propre `setupNodeEvents`, pas de config partagée par défaut. - cypress/support/component.ts + component-index.html : fichiers de support standards Cypress CT — importe le vrai global.scss de l'appli (les composants génériques sont stylés via lui, pas de CSS scopé à eux). - cypress/component/CheckboxOption.cy.tsx : 4 scénarios sur components/ui/Checkbox.tsx (rendu du label, reflet du prop `checked` sur l'input natif + la classe `is-selected`, callback `onChange` avec la valeur inversée, comportement contrôlé via un wrapper avec état). Dépendance ajoutée, épinglée : @cypress/vite-dev-server@5.2.1 (dernière version sans peer dependency cypress >=14 — 6.0.3+ l'exige explicitement, on est sur cypress@13.17.0). Testé en local jusqu'au mur GPU/Electron habituel (config + devServer Vite chargent sans erreur) — l'exécution réelle du montage reste à vérifier via la CI. * ci: exécute les tests de composants Cypress Sans ça, `cypress/component/CheckboxOption.cy.tsx` (commit précédent) ne tournait jamais en CI : `pnpm --filter web e2e` lance `cypress run` sans `--component`, donc uniquement la suite e2e par défaut. - apps/web/package.json : nouveau script `cy:run:component` - ci.yml : étape dédiée après `pnpm --filter web e2e`, sans start-server-and-test (Cypress lance son propre dev server Vite en interne pour le component testing, pas besoin d'attendre l'appli comme pour l'e2e) * test(web): refactor user journeys into Cucumber scenarios Convertit les parcours utilisateur (goal-driven, "en tant que X je peux Y") en scénarios Gherkin, en réutilisant l'infra Cucumber déjà validée par le smoke test (PR #24). Retire le smoke test jetable maintenant superflu. 8 fichiers .feature ajoutés, chacun avec son fichier de step definitions au même basename (convention de découverte du préprocesseur — voir login-smoke.ts) : - auth.feature : inscription (succès, erreur validation, email déjà pris), connexion (succès, identifiants invalides), déconnexion - onboarding.feature : les 3 scénarios déjà couverts (wizard complet, étapes sautées, rejoindre un foyer pendant l'onboarding) — dépend de household-settings.ts et preferences.ts pour ses steps de création/rejoint de foyer et de sélection de régime/allergies - household-settings.feature : créer un foyer, rejoindre par code d'invitation, renommer (autosave), retirer un membre, supprimer le foyer, quitter le foyer - account.feature : suppression de compte (mauvais mot de passe, succès, annulation) - recipe-form.feature : les 4 scénarios déjà couverts inchangés (ajout d'ingrédient + création, régression crypto.randomUUID, exclusion/ réinclusion d'ingrédient, préchargement + édition d'une recette existante) - recipes.feature : bascule favori, suppression d'une recette - preferences.feature : autosave du régime, autosave des allergies - user-preferences.feature : changement de thème (autosave) En contrepartie, les anciens .cy.ts perdent uniquement les it() migrés vers Gherkin — les scénarios de layout/affichage pur (catalogue de recettes, tabs, recherche, panneau de détail, sidebar, planning grid, etc.) restent en Cypress classique, conformément au découpage "parcours utilisateur (Cucumber) vs layout (Cypress pur)" déjà en place pour les component tests. auth.cy.ts, onboarding.cy.ts et recipe-form.cy.ts sont supprimés : 100% de leur contenu a migré. Les commentaires "voir auth.cy.ts pour la justification" désormais obsolètes (fichier supprimé) sont remplacés par une explication autonome du mock cy.intercept. Vérifié statiquement : les 246 steps Gherkin des 8 .feature résolvent chacun vers exactement une définition (0 non résolu, 0 ambigu) et `pnpm exec biome check` est propre sur tout cypress/. Reste à confirmer en CI que les scénarios passent réellement (pas seulement qu'ils se résolvent). * fix(web): fix cross-feature step discovery and slash-alternation bug La CI de la refonte précédente (commit aaace15) a échoué : la découverte par défaut du préprocesseur ne charge, pour un fichier `foo.feature`, QUE `foo.ts` (co-localisé, même basename) et `cypress/support/step_definitions/**` — pas les autres `.ts` du dossier `cypress/e2e/`. onboarding.feature référençait donc des steps qui ne vivaient que dans preferences.ts, household-settings.ts et auth.ts, introuvables lors de son propre run. Déplace les steps réellement partagés entre plusieurs .feature vers cypress/support/step_definitions/ (chargé pour toutes les features) : - reference-data.steps.ts : mocks des listes de référence régimes/ allergies (options ou vides) — partagé entre auth.feature et onboarding.feature - household-mutations.steps.ts : création/adhésion à un foyer et leurs assertions — partagé entre household-settings.feature et onboarding.feature - profile-mutations.steps.ts : sélection du régime, mise à jour des allergies et leur assertion — partagé entre preferences.feature et onboarding.feature Les définitions d'origine sont retirées de auth.ts/household- settings.ts/onboarding.ts/preferences.ts pour éviter un step "Ambiguous" (chargé deux fois pour la feature qui les définissait déjà elle-même). Corrige aussi un second bug distinct révélé par la même CI : "the ingredient/diet catalog is available" (recipe-form.feature) contient un "/" non échappé — en syntaxe Cucumber Expression, "/" hors d'un paramètre {..} signifie une alternative de texte ("ingredient" OU "diet catalog is available"), jamais le caractère littéral. Le texte du .feature ne pouvait donc jamais matcher. Renommé sans "/" : "the ingredient and diet catalog is available". Le script de vérification statique utilisé pour valider aaace15 avant push donnait une fausse confiance : il regroupait tous les steps de tous les fichiers comme disponibles globalement pour chaque feature, sans respecter ce scoping réel. Réécrit pour ne charger, par feature, que son fichier co-localisé + step_definitions/ — et pour détecter les patterns contenant un "/" non échappé. Résultat : toujours 246 steps, 0 non résolu, 0 ambigu, 0 pattern à slash non échappé, cette fois avec un modèle de résolution fidèle au comportement réel du préprocesseur. * test(web): cover every CheckboxOption/RadioOption behavior Complète les component tests des deux seuls composants UI génériques committés (Dialog.tsx est un WIP non commité d'une autre fonctionnalité en cours — hors scope ici) pour couvrir tout leur comportement, pas seulement le cas heureux. CheckboxOption — 4 tests existants (rendu, checked/is-selected, onChange au clic depuis unchecked, contrôlé) complétés par : - onChange(false) au clic depuis l'état checked (symétrique du test existant, qui ne couvrait que checked=false → true) - fusion du className de l'appelant avec is-selected, dans les deux sens (juste className, className+is-selected) - class="" (chaîne vide, pas "false"/"null") quand aucun className n'est passé et que checked=false — pin le comportement exact du `.filter(Boolean).join(" ")` - le clic sur le texte du label (pas seulement l'input) déclenche aussi onChange — comportement natif du HTML dont la "carte sélectionnable" de global.scss dépend entièrement - le span .check-mark est aria-hidden RadioOption — aucun test avant ce commit. Ajouté en couvrant en plus ce qui distingue vraiment un radio d'un checkbox : - name/value posés sur l'input natif - onChange(value) au clic depuis unchecked - AUCUN onChange au clic sur un radio déjà checked (contrairement à un checkbox, un radio natif ne réémet pas `change` si l'état ne change pas réellement) - clic sur le label, className/is-selected, aria-hidden — mêmes scénarios que CheckboxOption - comportement de groupe mutuellement exclusif : 3 RadioOption partageant `name="theme"` (mirroring UserPreferencesPage), un seul sélectionné à la fois, y compris via `input:checked` natif du navigateur Non exécutable en local (limitation GPU/sandbox Electron documentée dans le README, pré-existante) — à vérifier en CI. * test(web): add layout/style regression suite for the app shell Troisième catégorie du découpage des tests (parcours via Cucumber, composants génériques via Component Testing, et maintenant layout pur — indépendant de tout parcours utilisateur). Cypress classique, pas de Gherkin : ce fichier teste la structure/l'apparence du shell (AppLayout) lui-même, pas le contenu d'une page donnée. Couvre spécifiquement les 4 axes demandés : - Positionnement : la sidebar garde une largeur fixe (240px déplié, 68px replié) plaquée au coin haut-gauche, sur n'importe quelle page. - Scroll : régression directe pour #21 — `.app-layout` reste borné exactement à la hauteur du viewport (overflow: hidden), et une page plus haute que le viewport scrolle uniquement dans `.app-content` (via un spacer synthétique de 3000px injecté après le mount, pour rester indépendant du contenu réel d'une page donnée) sans jamais déplacer la sidebar ni scroller le document lui-même. - Largeur des pages : autre régression directe pour #21 — le planning et le catalogue de recettes remplissent toute la largeur disponible de `.app-content`, tandis que la page "Liste de courses" et les pages de paramètres restent centrées avec un espace égal de chaque côté (le bug original : collées à gauche avec un grand vide à droite). - Breakpoint responsive (< 640px) : la sidebar bascule en barre horizontale pleine largeur, masque le bouton collapse/la version, et garde chaque lien de nav pleinement lisible (icône + label, avec scroll horizontal) plutôt que de les écraser en pastilles de ~16px sans texte — un mode de régression explicitement documenté en commentaire dans AppLayout.scss mais jusqu'ici non testé. - Thème de couleur : va au-delà de l'attribut `data-theme` déjà couvert par user-preferences.cy.ts — vérifie les vraies valeurs de couleur calculées (`getComputedStyle`) sur la sidebar, le lien de nav actif et le fond de page, en clair et en sombre, confirmant que la cascade CSS des tokens (_theme.scss) atteint réellement le rendu, pas seulement que le JS pose le bon attribut. Non exécutable en local (limitation GPU/sandbox Electron documentée dans le README, pré-existante) — à vérifier en CI.	2026-08-19 14:31:17 +02:00
Nicolas	cdca6f61f4	Tests: couverture Cypress pour le repli/déploiement de la sidebar ... Repli/déploiement via le bouton dédié, labels masqués (pas retirés du DOM — restent pour le title="") mais liens toujours visibles/cliquables icône seule, persistance via localStorage vérifiée après cy.reload().	2026-08-17 16:17:06 +02:00
Nicolas	a8d897dfab	Tests: couverture Cypress pour les préférences utilisateur (step 4/4) ... - user-preferences.cy.ts: défaut SYSTEM, thème sauvegardé restitué et appliqué au document, autosave sans bouton "Enregistrer" - sidebar.cy.ts: 4 pages de paramètres (libellé "Préférences alimentaires" renommé + nouvelle entrée "Préférences utilisateur") - auth.cy.ts/onboarding.cy.ts: corrige un intercept **/planning/current périmé (route supprimée dans la PR précédente) — masqué jusqu'ici car aucune assertion n'en dépendait directement, mais provoquait un appel réseau non mocké	2026-08-17 15:56:36 +02:00
Nicolas	26453dd757	Tests: couverture Cypress pour les paramètres, l'onboarding et la sidebar (step 8/8) ... - household.cy.ts scindé en preferences.cy.ts (régime/allergies) et household-settings.cy.ts (nom, créer/rejoindre/membres/suppression/ quitter, avec et sans droits admin) - onboarding.cy.ts réordonné (régime → foyer → allergènes), avec les cas skip / créer / rejoindre à l'étape foyer - account.cy.ts: identité, suppression de compte (erreur de mot de passe, succès, annulation) - sidebar.cy.ts: menu Paramètres (3 liens) et menu compte (Mon compte, déconnexion), redirection /foyer → /parametres/foyer - auth.cy.ts/home-planning.cy.ts: adaptés au nouveau menu compte et au premier écran d'onboarding (régime, plus foyer)	2026-08-17 10:49:19 +02:00