Nicolas
615e320be1
Some checks failed
Sur un vrai navigateur mobile Android (isAndroidPhoneBrowser(), déjà utilisé par le ticket #84), la ligne de CTA de la landing page affiche désormais "Ouvrir dans l'application" comme action PRIMAIRE — plus utile qu'un compte web puisque l'expérience web n'est de toute façon pas optimisée mobile (au cœur de ce chantier), et un visiteur avec l'appli déjà installée peut s'inscrire/se connecter depuis l'appli elle-même. "Créer un compte"/"Se connecter" sont rétrogradés en actions secondaires plutôt que masqués : certains visiteurs préfèrent sciemment le web. Le clic déclenche attemptOpenNativeApp (tentative d'ouverture du scheme, repli automatique après le délai) plutôt que d'afficher un second lien séparé — remplace .landing__mobile-link, ne le duplique pas. Sur desktop, comportement inchangé (CTA "Créer un compte" toujours primaire) sauf le lien Android discret, qui pointe maintenant vers /telecharger (page de repli du ticket #84) au lieu du lien direct /mobile/download — un seul point d'entrée "obtenir l'appli" pour tout le site plutôt que deux mécanismes légèrement différents à maintenir en synchro. Couverture Cypress : landing.feature étendu avec un nouveau scénario mobile (UA Android spoofée via onBeforeLoad, même chaîne que le test unitaire existant d'isAndroidPhoneBrowser dans mobile-app-redirect.cy.tsx) — vérifie l'affichage du bouton et la rétrogradation de Créer un compte/Se connecter, SANS jamais cliquer le bouton réel (son onClick appellerait un vrai window.location.href vers un scheme personnalisé, qui bloque indéfiniment le runner Cypress/ Electron — piège déjà documenté, la fonction elle-même est déjà testée unitairement avec un stub injecté). Le scénario desktop existant est mis à jour pour le nouveau href /telecharger. Suite complète : biome check, tsc -b --force, build, 145/145 e2e, 71/71 composants — tous verts. Closes #85 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
46 lines
1.8 KiB
Gherkin
46 lines
1.8 KiB
Gherkin
Feature: Public landing page at the root
|
|
|
|
A logged-out visitor on "/" should see a real presentation of the app
|
|
before being asked to sign in — but every other guarded route, and a
|
|
logged-in visitor, must behave exactly as before.
|
|
|
|
Scenario: A logged-out visitor lands on the presentation page
|
|
Given I am not signed in
|
|
When I visit "/"
|
|
Then I should see the heading "Cuisinez une fois, mangez toute la semaine"
|
|
And I should see the landing call to action
|
|
|
|
Scenario: The landing page sends visitors to sign in
|
|
Given I am not signed in
|
|
And I visit "/"
|
|
When I click the link "Se connecter"
|
|
Then the URL should include "/login"
|
|
|
|
Scenario: The landing page sends visitors to create an account
|
|
Given I am not signed in
|
|
And I visit "/"
|
|
When I click the link "Créer un compte"
|
|
Then the URL should include "/signup"
|
|
|
|
Scenario: The landing page offers the Android app download, on desktop
|
|
Given I am not signed in
|
|
When I visit "/"
|
|
Then I should see the Android download link
|
|
|
|
Scenario: A mobile visitor is offered to open the app first, not just a download link
|
|
Given I am not signed in
|
|
When I visit "/" as an Android phone browser
|
|
Then I should see the button to open the app, with sign-up demoted to secondary
|
|
And the Android download link should not be shown
|
|
|
|
Scenario: Another guarded route still redirects a logged-out visitor to sign in
|
|
Given I am not signed in
|
|
When I visit "/recettes"
|
|
Then the URL should include "/login"
|
|
|
|
Scenario: A signed-in visitor on "/" still gets the planning, not the landing
|
|
Given I am signed in as "Alice" "Martin"
|
|
And the planning request returns nothing
|
|
When I visit "/"
|
|
Then I should see the heading "Planning de la semaine"
|
|
And I should not see "Cuisinez une fois, mangez toute la semaine"
|