cypress/
├─ e2e/                       # Tous les tests end-to-end
│  ├─ login/
│  │   └─ login.cy.ts         # Tests du module Login
│  │   
│  ├─ profile/                # Tests de la fonctionnalité Profile avec Cucumber
│     └─ profile.feature      # Fichier de test en langage Gherkin
│     └─ profile.ts           # Fichier de Step Definitions correspoandant
│
├─ pages/                     # Page Objects (POM hybride)
│  ├─ login/
│  │   └─ loginPage.ts
│  │
│  ├─ profile/
│  │   └─ profilePage.ts
|  |
|  ├─ basePage.ts             # Méthodes transverses (visit, getByTestId…)
|  ├─ pageTemplate.ts         # Gabarit pour cloner de nouvelles pages
|   
│
├─ fixtures/                  # Données statiques de test
│  └─ users.json
│
├─ support/                   # Helpers globaux Cypress
│  ├─ commands.ts             # Custom commands (ex: cy.dataTestid)
│  ├─ index.d.ts              # Typages pour autocomplétion TS
│  └─ e2e.ts                  # Fichier bootstrap exécuté avant tests
│
└─ utils/                     # Utils réutilisables hors Cypress
|  └─ api.ts                  # Fonctions utilitaires pour API calls
|  
|
│
├─ plugins/                  # Plugins Cypress (ex: pour allure, reports, etc.)
│   └─ index.ts
│
├─ cypress.config.ts         # Config Cypress (baseUrl, viewport, timeout…)
└─ tsconfig.json             # Configuration TypeScript pour CypressLangage du code : Markdown (markdown)

🔹 Points clés de cette structure

1. Pages/ → contient toutes les classes POM.

. BasePage pour les méthodes génériques.

. Chaque page concrète a ses getters et Fluent API.

. pageTemplate.ts pour cloner facilement de nouvelles pages.

2. E2E / → contient les tests d’intégration organisés par fonctionnalité/page.

. Chaque sous-dossier correspond à une feature de l’app.
. Chaque cy ne doit tester qu’une fonctionnalité ou un flux.

3. support/ → contient :

. commands.ts pour les helpers transverses (ex. cy.dataTestid(), cy.resetDatabase()).
. index.d.ts pour le typage TypeScript de tes commandes.
. e2e.ts pour l’initialisation globale (ex. importer commands, hooks globaux comme beforeEach() pour login si nécessaire).

4 Fixtures/ → données statiques utilisées dans les tests.

Ex: utilisateurs de test, payload API, mocks JSON.

5. Utilitaires.

cypress/
└─ utils/
   ├─ dom.ts         # fonctions liées au DOM
   ├─ api.ts         # helpers pour appels HTTP / REST / GraphQL
   ├─ format.ts      # fonctions de formatage (dates, nombres, strings…)
   ├─ data.ts        # générateurs de données aléatoires ou mock
   └─ auth.ts        # fonctions liées à l’auth (token, cookies…)Langage du code : Markdown (markdown)

. Ex : formatter des dates, générer des tokens JWT, etc.
. Permet de séparer la logique “business utilitaire” du pur POM Cypress.

6. plugins/ → plugins Cypress optionnels (reporting, allure, code coverage…).

7. cypress.config.ts et tsconfig.json → config Cypress + TypeScript pour tout le projet.

🔹 Bonnes pratiques avec cette structure

. Indépendance des tests : chaque it() doit pouvoir être exécuté seul.

. Lisibilité : les tests E2E restent courts et lisibles grâce à POM.

. Réutilisabilité : BasePage + pageTemplate pour créer facilement de nouvelles pages.

. Séparation claire :

. Logique de page → pages/ = encapsulation UI (POM hybride)

. Actions transverses → commands.ts

. Données → fixtures/

. Tests → e2e/ = logique métier des scénarios de test